EIDO & IDX FAQ (Frequently Asked Questions): Difference between revisions

From NENA Knowledge Base
Content added Content deleted
VisualWikitext
(Changed "EIDD" to "EIDO" to reflect new JSON - based format and standard.)
Line 1:
NENA-REF-011.1-2018X (DRAFT)
 
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.
 
== EIDDEIDO Questions & Answers ==
 
=== What is an EIDDEIDO? ===
"'''EIDDEIDO'''" is an abbreviation for '''<big>E</big>'''mergency '''<big>I</big>'''ncident '''<big>D</big>'''ata '''<big>DO</big>'''ocumentbject.
 
Here's the official NENA Master Glossary [[EIDD (Emergency Incident Data Document)|definition]]:
Line 12 ⟶ 14:
''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 EIDDEIDO:
 
The EIDDEIDO 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 EIDDsEIDOs? ===
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 [[FE (Functional Element)|functional elements (FE)]].
 
=== Where are the EIDDEIDO specifications? ===
There are several documents where the specifications and requirements relating to EIDDsEIDOs are published:
* '''The formatrequirements andfor XMLPSAP schemafunctional elements for EIDDssending and receiving EIDOs''' isare specifiedincluded in an APCO/NENA standard that can be downloaded:the [https://www.nena.org/page/EIDD?NG911_PSAP_REQ NENA/APCO EmergencyNG9-1-1 IncidentPSAP DataRequirements Document] where (EIDD)]they were described as "EIDDs".
* '''TheEIDOs requirementsused for PSAPtransferred functionalcalls elementsand forother sendingaspects andof receiving EIDDsEIDOs''' are includedpublished in the [https://www.nena.org/?NG911_PSAP_REQpage=i3_Stage3 NENA/APCO NG9-1STA-1010 PSAPDetailed RequirementsFunctional Document]and Interface Standards for the NENA  i3 Solution]
* '''EIDDs used for transferred calls and other aspects of EIDDs''' are published in [https://www.nena.org/?page=i3_Stage3 NENA-STA-010 Detailed Functional and Interface Standards for the NENA  i3 Solution]
 
NENA Working Groups are currently developing additional documentation for EIDDsEIDOs and their use:
* '''EIDDEIDO Conveyance:''' [https://www.nena.org/?page=InterconnectSecurity Conveyance of Emergency Incident Data Document (EIDDEIDO) Working Group]
* '''EIDDEIDO Management:''' [https://www.nena.org/?page=PSAP_Operations Management of Emergency Incident Data Documents (EIDDEIDO)]
* '''IDX Functional Element:''' [https://www.nena.org/?page=InterconnectSecurity i3 Architecture]
* '''EIDDEIDO Specifications for NG9-1-1 PSAP Functional Elements:''' [https://www.nena.org/?page=AgencySystems NG9-1-1 PSAP SYSTEMS] where they were described as "EIDDs".
 
=== What kind of information is in an EIDDEIDO? ===
An EIDDEIDO 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. EIDDsEIDOs will often include the caller's information like name, number, and location. EIDDsEIDOs 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 EIDDEIDO in the [https://www.nena.org/page/EIDD NENA/APCO Emergency Incident Data Document (EIDD)]-INF-005. There is also a handy Excel spreadsheet guide to all of the kinds of XML elements that there can be in an1 EIDD in the [https://niemDocument.gtri.gatech.edu/niemtools/iepdt/download/resource.iepd?ref=__bVqwEPq3o EIDD Mapping Spreadsheet].
 
=== Is there a standard XMLJSON schema for the EIDDEIDO? ===
The JSON EIDO schema is under development.
Yes. The [[NIEM (National Information Exchange Model)|NIEM]]-Conformant [[IEPD (Information Exchange Package Document)]] is available here: [https://niem.gtri.gatech.edu/niemtools/iepdt/display/container.iepd?ref=CPnFNm8J4lA NIEM IEPD (Schemas & other documents)]
 
=== What is the relationship between an incident record and EIDDEIDO? ===
An incident record is an internal representation of the incident information and is typically proprietary to an agency’s system. An EIDDEIDO 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”EIDO” button to send EIDDsEIDOs to other systems? ===
No – the system sends EIDDsEIDOs 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 EIDDsEIDOs being sent, rather than the button push.
 
=== How are EIDDsEIDOs generated? ===
An EIDDEIDO is a data object, an XML data object specifically. EIDDsEIDOs are generated by software in response to changes in incident status. Some EIDDsEIDOs 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. EIDDsEIDOs will not be displayed to users directly. Some user interface may (or may not) change in response to receipt of an EIDDEIDO, but that depends on the function of the user interface and its implementation. EIDDsEIDOs 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 EIDDEIDO a complete record of the call, or something less? ===
No, an EIDDEIDO represents the state of an Incident, which may have zero or more Calls associated with it. An EIDDEIDO 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 & IDX FAQ (Frequently Asked Questions)#If an EIDD is not a complete record of the call.2C how does that look.3F|EIDDEIDO FAQ# 1.10]])
 
=== If an EIDDEIDO is not a complete record of the call, how does that look? ===
An EIDDEIDO only includes INCIDENT (not just “call”) information as known by the FE that is generating the EIDDEIDO at the time it was sent. If there is a change in the state of an incident, that change is included in a new EIDDEIDO. The EIDDEIDO has no incident history.
 
=== Is an EIDDEIDO only a snapshot in time that carries data from one point to another? ===
Yes.
 
=== Does the EIDDEIDO 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 EIDDEIDO? ===
The EIDDEIDO Conveyance working group is writing standards that define how EIDDsEIDOs are sent ("conveyed”). Current draft text provides several mechanisms including a “push” mechanism where the FE that creates the EIDDEIDO 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 EIDDEIDO to, for example, a Dispatch FE, to request dispatch. The sender includes in the EIDDEIDO 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 EIDDsEIDOs 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 EIDDEIDO is only a snapshot in time, where are the EIDDEIDO transactions logged? ===
EIDDsEIDOs must be logged when they are sent. To get history, you query the logger of the sender. EIDDsEIDOs 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 EIDDEIDO have a complete history of the incident at the time it is first generated and then only updates after that? ===
An EIDDEIDO represents the state of an incident as known by the sender at the time the EIDDEIDO was sent. The EIDDEIDO 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 EIDDEIDO and send it. That updates the incident at the recipient. At present, the draft conveyance text expects each EIDDEIDO 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 EIDDEIDO was sent, they get it from the logger. If they need to know the state after an EIDDEIDO was sent, they subscribe to the incident at the sender, and they will get new EIDDsEIDOs when state changes.
 
=== Other i3 data items can be sent “by value” or “by reference”. What does EIDDEIDO 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 EIDDEIDO (value). Similarly, an FE can create a URI which is used with the subscription service to receive EIDDsEIDOs. The subscription URI is another form of EIDDEIDO 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“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 EIDDEIDO by reference.
 
=== How do I control what EIDDEIDO information is made available? ===
As with all i3 services, the content of the EIDDEIDO, 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 EIDDEIDO owner determines who can use these services and what data they can obtain from these services.
 
=== When an EIDDEIDO 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 EIDDEIDO. If the GET is repeated later, a new EIDDEIDO with current state is returned.
 
=== When does an EIDDEIDO 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 EIDDEIDO would change is sufficient to generate a new EIDDEIDO. However, with the subscription service, the recipient can specify content, rate and/or location filter criteria that affects when it receives EIDDsEIDOs. All filters can reduce the number of EIDDsEIDOs sent, but the rate filter also has a minimum rate specification, which if used can cause an EIDDEIDO to be sent even when no value changes.
 
=== Does the EIDDEIDO 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 EIDDEIDO? ===
The current proposed transport draft uses Subscribe/Notify to send updated EIDDsEIDOs. 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 EIDDsEIDOs using the rate filters.
 
=== The APCO-NENA EIDDEIDO INF document says that an EIDDEIDO does not provide historical data. What does that mean? ===
It means that you only get 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 EIDDEIDO received for this incident, but see below*. The EIDDEIDO itself doesn’t indicate that something changed. The UI determines what the agent/user becomes aware of, and how they are notified.
 
<nowiki>*</nowiki> The conveyance document describes the use of “rate” filters, one of which is a minimum rate. An EIDDEIDO may be sent to achieve the minimum rate, which may not have any fields different from the prior EIDDEIDO.
 
=== Where do EIDDEIDO data files get stored? ===
They don’t get stored. There is no such thing as a “EIDD“EIDO data file”. EIDDsEIDOs sent are logged, so there is a copy in the logging service of the sender. Received EIDDsEIDOs may be logged, so there may be a copy in the logging service of the recipient. Anything else is implementation dependent. Systems that exchange EIDDsEIDOs probably store the information in their own incident record. Neither the EIDDEIDO standard nor STA-010 define how the data in EIDDEIDO messages must be physically stored in FEs that exchange EIDDEIDO messages.
 
=== Is there a way to show the recipient that current data within the EIDDEIDO 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 EIDDEIDO sent? ===
An EIDDEIDO is sent when a significant change in incident state changes. At minimum, at least one data component in the EIDDEIDO has to change from the prior EIDDEIDO sent for this incident. Also see EIDDEIDO [[EIDD & IDX FAQ (Frequently Asked Questions)#When does an EIDD get generated from triggered events .28e.g..2C note-taking.3F|FAQ# 1.20]], and EIDDEIDO [[EIDD & IDX FAQ (Frequently Asked Questions)#How do I determine that something has changed during the course of an incident.3F|FAQ# 1.23]].
 
Policy in the sender may restrict sending an EIDDEIDO 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? ===
Line 110 ⟶ 111:
 
=== Does it create a map? ===
EIDDsEIDOs don’t create a map. Information in the EIDDEIDO 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 EIDDEIDO? ===
“Rebid” would create a new EIDDEIDO 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 EIDDEIDO vs Incident Record ===
“Incident Record” is not standardized, EIDDEIDO is. An implementation may have more data (non-standardized) in its local incident record than in an EIDDEIDO.
 
(Also see EIDDEIDO FAQ# 6)
 
=== What notes are updated? ===
There is a data component in an EIDDEIDO 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 EIDDEIDO that has a change in that data component.
 
=== Which PSAP workflows will generate an EIDDEIDO? ===
EIDDsEIDOs 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 EIDDEIDO data components: when any of those data components has at least one element that changes, the agency that determines the changes sends EIDDsEIDOs. Events that might cause an EIDDEIDO 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)
Line 131 ⟶ 132:
* Clearing operations
 
=== How is access to the information in an EIDDEIDO controlled? ===
Standard NG9-1-1 Data Rights Management mechanisms apply to EIDDsEIDOs. 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 EIDDEIDO generated? ===
Reason for Issue values are defined in a Registry managed by the NENA Registry System, located at: http://technet.nena.org/nrs/registry/EIDD-ReasonForIssue.xml. Creating a new value requires a specification document and expert review.
 
=== An EIDDEIDO contains Current State. What does Current State always include? ===
Current state, as known by the entity sending the data at the time the EIDDEIDO 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 EIDDEIDO. Those are listed as ‘mandatory’ elements in the EIDDEIDO header, as shown in the APCO-NENA EIDD Standard, found at: http://www.nena.org/?EIDD.
 
== IDX Questions and Answers ==
 
=== What is the purpose of an IDX? ===
An Incident Data Exchange (IDX) is a functional element that aggregates EIDDEIDO information from multiple FEs within an agency and creates a composite EIDDEIDO that represents the entire state of an incident as known by the agency at the time the aggregated EIDDEIDO was sent by the IDX. To accomplish this task, the IDX receives EIDDsEIDOs from all the constituent FEs within the agency and combines them using an algorithm to create a single composite EIDDEIDO. FEs or agencies inside or outside the agency can then obtain the composite EIDDEIDO 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 EIDDsEIDOs from all the agencies involved in an incident and creates a composite view of the incident from the constituent EIDDsEIDOs. Any (authorized) agency can then get a unified view of the incident by obtaining an EIDDEIDO 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 EIDDsEIDOs ===
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 EIDDsEIDOs by reference? ===
The IDX may deliver coalesced EIDDsEIDOs by reference. If it does so, then it does the dereferencing for those references.
 
=== Is the IDX capable of receiving a constituent EIDDEIDO ‘by reference’? ===
No. The IDX always subscribes to the FEs that supply it constituent EIDDsEIDOs, therefore the EIDDsEIDOs are sent by the FEs, to the IDX ‘by value’.
 
=== If an EIDDEIDO is received by an IDX containing data ‘by reference’, what is in the coalesced EIDDEIDO 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 EIDDEIDO, 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 EIDDsEIDOs 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 EIDDEIDO? Where mediate means that all requests for EIDDsEIDOs go through an IDX. ===
Within an agency, one FE may send/receive EIDDsEIDOs to other FEs directly.
 
For FEs outside the agency, see [[EIDD & IDX FAQ (Frequently Asked Questions)#How does an FE locate the IDX.3F|FAQ 2.8]]
Line 177 ⟶ 178:
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 EIDDsEIDOs be exchanged without an IDX? ===
Yes. An FE can exchange EIDDsEIDOs directly with other FEs. This might be implementation specific. In addition STA-010 specifies how to include an EIDDEIDO 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).
 
=== EIDDsEIDOs may have sensitive information, how is that information protected? ===
Security for EIDDEIDO exchanges is no different than any other exchange in i3. Credentials will be used for all EIDDEIDO 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 EIDDEIDO is the policy that is determinant as to what information is allowed to be exchanged.
 
=== How does an FE that receives an EIDDEIDO send information it receives in an EIDDEIDO that it sends? ===
In general, FEs may not send information they receive from another entity. However, if an FE receives a reference to an EIDDEIDO (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 EIDDEIDO 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? ===
Line 193 ⟶ 194:
 
=== What credentials are used by an FE (including an IDX)? ===
Any entity sending or receiving an EIDDEIDO 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 EIDDEIDO related transactions? ===
No. The Logging Service performs this function.
 
=== IDX vs. Logging Service: which element knows about every EIDDEIDO 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.
 
Line 205 ⟶ 206:
 
=== 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 EIDDEIDO 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 EIDDEIDO is only a snapshot in time, where are the EIDDEIDO 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 EIDDEIDO 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 EIDDEIDO ‘by reference’ to B, B goes back to A to dereference it.
 
When B transfers the incident to C, if B send the EIDDEIDO 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 EIDDEIDO ‘by value’, then C doesn’t need to dereference, but may still opt to request current state and updates from A.
 
== References ==
 
=== From the APCO NENA spec, https://c.ymcdn.com/sites/www.nena.org/resource/resmgr/standards/APCO_NENA_2.105.1-2017_EIDD_.pdf ===
[from the section titled “Usage”:
 
The EIDD provides a standard for exchanging emergency incident related information. The EIDD represents the state of an emergency incident as known by a functional element or a single agency. An EIDD should be generated and exchanged among interested systems and stakeholders anytime that a significant change occurs in the incident’s state.
 
For example, among other possible triggers, an EIDD is generated and distributed anytime a 9-1-1 call is answered, a call taker enters notes about an incident, an emergency incident’s location is established or changed, an incident is classified or reclassified (structure fire, vehicle accident with injuries, assault, etc.), emergency responders are dispatched, emergency responders arrive on scene, and when an emergency incident is closed with a final disposition.
 
The EIDD provides information about the current state of an incident. It does not provide historical information about the incident. The Logging Service (see NENA-STA-010) is used to obtain historical information about an incident. An EIDD is usually associated with an active emergency incident. To support mutual and automatic aid, an EIDD can be used to report changes in an emergency responder’s state without that EIDD being associated with an incident.
 
EIDDs may contain sensitive and confidential information and should never be exchanged with another entity without first authenticating that entity and establishing its privileges (see NENA-STA-010, section 6.5: Authorization and Data Rights Management) to view the information contained in the EIDD. EIDDs may be filtered to remove sensitive and confidential information based on the authenticated privileges of the entity receiving the EIDD.
 
=== NENA-STA-010 ===

Revision as of 14:47, 4 June 2019

NENA-REF-011.X (DRAFT)

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 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 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:

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

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 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, an XML 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 APCO-NENA EIDO INF document says that an EIDO does not provide historical data. What does that mean?

It means that you only get 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# 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.

References

NENA-STA-010

NENA Detailed Functional and Interface Standards for the NENA i3 Solution

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