3,018
edits
EIDO & IDX FAQ (Frequently Asked Questions): Difference between revisions
EIDO & IDX FAQ (Frequently Asked Questions) (view source)
Revision as of 20:49, 9 January 2024
, 5 months agoRemoved bad links
MikeVislocky (talk | contribs) (→The APCO-NENA EIDD INF document says that an EIDD does not provide historical data. What does that mean?: Fixed order of NENA-APCO) |
MikeVislocky (talk | contribs) (Removed bad links) |
||
| (13 intermediate revisions by 2 users not shown) | |||
Line 1:
NOTE: "EIDO" refers to a JSON - formatted Emergency Incident Data Object. The EIDO specification in development is based on the [https://www.nena.org/page/EIDD_INF 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.
Line 10 ⟶ 9:
"'''EIDO'''" is an abbreviation for '''<big>E</big>'''mergency '''<big>I</big>'''ncident '''<big>D</big>'''ata '''<big>O</big>'''bject.
Here's the
''A
Here are some other ways to describe an EIDO:
Line 49 ⟶ 48:
=== 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 [[
=== If an EIDO is not a complete record of the call, how does that look? ===
Line 104 ⟶ 103:
=== 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 [[
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.
Line 120 ⟶ 119:
“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 [[EIDO & IDX FAQ (Frequently Asked Questions)#What is the relationship between an incident record and EIDO.3F|FAQ# 1.6]])
=== What notes are updated? ===
Line 175 ⟶ 174:
Within an agency, one FE may send/receive EIDOs 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]]
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.
Line 224 ⟶ 223:
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.
{{RelevantNENADocs}}
▲[https://www.nena.org/page/i3_Stage3 NENA Detailed Functional and Interface Standards for the NENA i3 Solution]
▲[[Category:Proposed Draft]]
| |||