Emergency Data Exchange Language Situation Reporting (EDXL-SitRep) Version 1.0
Committee Specification Draft 03 /
Public Review Draft 03
11 August 2015
Specification URIs
This version:
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csprd03/edxl-sitrep-v1.0-csprd03.odt (Authoritative)
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csprd03/edxl-sitrep-v1.0-csprd03.html
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csprd03/edxl-sitrep-v1.0-csprd03.pdf
Previous version:
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs01/edxl-sitrep-v1.0-cs01.doc (Authoritative)
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs01/edxl-sitrep-v1.0-cs01.html
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs01/edxl-sitrep-v1.0-cs01.pdf
Latest version:
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/edxl-sitrep-v1.0.odt (Authoritative)
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/edxl-sitrep-v1.0.html
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/edxl-sitrep-v1.0.pdf
Technical Committee:
Chair:
Elysa Jones (elysajones@yahoo.com), Individual
Editors:
Rex Brooks (rexb@starbourne.com), Individual
Timothy Grapes (grapesco@outlook.com), Individual
Werner Joerg (wjoerg@computer.org), Individual
Additional artifacts:
This prose specification is one component of a Work Product that also includes:
Related work:
This specification is
related to:
·
Emergency Data
Exchange Language (EDXL) Distribution Element v1.0. Edited by Michelle Raymond, Sylvia Webb, and Patti Iles
Aymond. 01 May 2006. OASIS Standard. Latest version: http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf.
·
Emergency Data
Exchange Language (EDXL) Hospital AVailablity Exchange (HAVE) v1.0. Edited by Sukumar Dwarkanath. 22 December 2009. OASIS
Standard. Latest version: http://docs.oasis-open.org/emergency/edxl-have/v1.0/emergency_edxl_have-1.0.html.
·
Emergency Data
Exchange Language Resource Messaging (EDXL-RM) v1.0. Edited by Dr. Patti Aymond, Rex Brooks, Tim Grapes, Gary
Ham, Dr. Renato Iannella, Dr. Karen Robinson, Werner Joerg, and Alessandro
Triglia. 22 December 2009. OASIS Standard. Latest version: http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.html.
·
Emergency Data
Exchange Language (EDXL) Common Types (CT) v1.0. Edited by Werner Joerg, Rex Brooks, Jeff Waters, and Don
McGarry. 13 January 2015. Committee Specification Draft 03. Latest version: http://docs.oasis-open.org/emergency/edxl-ct/v1.0/edxl-ct-v1.0.html.
· Emergency Data Exchange Language (EDXL) Customer Information Quality (CIQ) Profile v1.0. Edited by Werner Joerg and Jeff Waters. 13 January 2015. Committee Specification Draft 04. Latest version: http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/edxl-ciq-v1.0.html.
· Emergency Data Exchange Language (EDXL) GML Simple Features Profile Version 1.0. Edited by Werner Joerg. 13 January 2015. Committee Specification Draft 02. Latest version: http://docs.oasis-open.org/emergency/edxl-gsf/v1.0/edxl-gsf-v1.0.html.
Declared XML namespaces:
Abstract:
This XML-based Emergency Data Exchange Language (EDXL) Situation Reporting specification describes a set of standard reports and elements that can be used for data sharing among emergency information systems, and that provide incident information for situation awareness on which incident command can base decisions.
Status:
This document was last revised or approved by the OASIS Emergency Management TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency#technical.
TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the Technical Committee’s web page at https://www.oasis-open.org/committees/emergency/.
For information on whether any patents have been disclosed that may be essential to implementing this Work Product, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/emergency/ipr.php).
Citation format:
When referencing this Work Product the
following citation format should be used:
[EDXL-SitRep]
Emergency Data Exchange
Language Situation Reporting (EDXL-SitRep) Version 1.0. Edited by
Rex Brooks, Timothy Grapes, and Werner Joerg. 11 August 2015. Committee Specification Draft 03 / Public Review Draft 03. http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csprd03/edxl-sitrep-v1.0-csprd03.html. Latest version: http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/edxl-sitrep-v1.0.html.
Notices
Copyright © OASIS Open 2015. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.
Table of Contents
All text is normative unless otherwise labeled.
The ongoing goal of the Emergency Data eXchange Language (EDXL) project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved.
The current roster of EDXL Standards includes:
· The Common Alerting Protocol v1.2 specification (EDXL-CAP)
· The Distribution Element specification v1.0 (EDXL-DE)
· The Hospital AVailability Exchange specification v1.0 (EDXL-HAVE)
· The Resource Messaging specification v1.0 (EDXL-RM)
The primary purpose of the Emergency Data Exchange Language Situation Reporting (EDXL-SitRep) Specification is to provide a set of standard formats for XML emergency response messages specifically aimed at transmitting timely situation reports. These situation reports are specifically designed as payloads of the Emergency Data Exchange Language Distribution Element (EDXL-DE). Together EDXL-DE and EDXL-SitRep are intended to expedite well-informed incident command decisions needed to respond effectively and adapt to emergency incidents, facilitating communication across various responding organizations and up the chain of command. The Distribution Element may be thought of as a container that provides the information to route "payload" message sets (such as alerts, hospital availability reports, resource messages or situation reports), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs.
The EDXL-SitRep message is constrained to the set of pre-defined Report types contained in this specification. The EDXL-SitRep message is intended to be the payload or one of the payloads of the Distribution Element which contains it.
Through a practitioner-driven approach, the Command, Control and Interoperability Division (CID) within the U.S. Department of Homeland Security's Science and Technology Directorate creates and deploys information resources to enable seamless and secure interactions among state, local, tribal, international, private entities, homeland security stakeholders and other federal entities. CID creates and deploys Information resources such as standards, frameworks, tools, and technologies.
CID is organized into five program areas: Basic/Futures Research; Cyber Security; Knowledge Management Tools; Office for Interoperability and Compatibility (OIC); and Reconnaissance, Surveillance, and Investigative Technologies.
Following voice interoperability programs such as SAFECOM, the OIC’s interoperable messaging standards program was initiated as one of the President’s e-Gov initiatives in 2001. The OIC mission is to serve as the standards program within the Federal Government to facilitate local, tribal, state, and federal public safety and emergency response agencies to improve emergency / disaster response through effective and efficient interoperable data sharing. OIC sponsors the process to facilitate practitioner requirements for the development of EDXL standards.
EDXL will accomplish this mission through the standardization of specific messages (XML messaging interfaces) which facilitate coordination and emergency communication between disparate software applications and systems - particularly when more than one profession or jurisdiction is involved.
The EDXL program is an open, public practitioner-driven process driven solely by cross-profession emergency practitioners through an OIC-sponsored Practitioner Steering Group (PSG) and Standards Working Group (SWG). The EDXL program is also a public-private partnership working with the EIC (Emergency Interoperability Consortium), Vendor communities, and OASIS (Organization for the Advancement of Structured Information Standards), which develops and publishes the open, public EDXL standards free of charge.
The OIC-sponsored Practitioner Steering Group (PSG) governance was formalized following publication of the EDXL Distribution Element. It plays a key role in the direction, prioritization, definition, and execution of the DHS-OIC program. The group is comprised of representatives of major emergency response associations and organizations, setting priorities and providing recommendations regarding messaging standards development as well as the other facets of the OIC-EDXL program.
The PSG identified the EDXL Situation Reporting (EDXL-SitRep) Specification effort as the top priority standard by this group following the development of EDXL-DE, EDXL-HAVE and EDXL-RM. Utilizing standard process and governance, the requirements and specification effort was initiated by this group in partnership with industry members of the Emergency Interoperability Consortium (EIC) and the Standards Working Group (SWG). The EDXL-SitRep draft specification was developed based on explicitly defined requirements which were submitted to the OASIS Emergency Management Technical Committee (EM-TC) to begin work on this international EDXL-SitRep standard.
Tthe EDXL Situation Reporting standard defines five (5) separate and specific report types to support incident command decision-making across the emergency incident life-cycle. This includes preparedness, pre-staging of resources, initial, ongoing response, recovery and demobilization / release of resources and after-action analysis to identify needed improvements in ongoing preparedness.
The EDXL Situation Reporting standard document structure is defined using successively more detailed or constrained artifacts in the form of textual descriptions, diagrams, figures, tables and Appendices. The EDXL-SitRep XML Schema is provided separately. The overall structure of the EDXL Situation Report is first represented in an Element Reference Model (ERM). The ERM is the foundation from which individual constraint schemas (individual situation report types) are defined.
The structure of the EDXL Situation Reporting standard is defined in the following sections:
· Section 3.1, The Element Reference Model (ERM), shows the abstract structural relationships of the main components of the EDXL-SitRep.
· Section 3.2, Distribution of EDXL Situation Reporting, describes practitioner requirements which are met through the EDXL-Distribution Element (DE)
· Sections 3.4.2 through 3.4.6 define the five (5) individual EDXL-SitRep report types
· Section 4 The Data Dictionary, defines each element contained in the EDXL-SitRep standard message
These sections together define the message structure, message element definitions, optionality and cardinality.
The following descriptions provide a brief overview of each EDXL-SitRep component to assist with an overall understanding of this standard's diagrams, figures and tables.
The Non-normative Element Reference Model diagram in Figure 2 of Section 3.1 shows the abstract structural relationships of the main components shown as packages of specific message elements. The EDXLSitRepRoot ERM diagram in Figure 3 of Section 3.3.1 shows the structural relationships of the main Situation Report elements used throughout the individual situation reports.
1. The EDXLSitRepRoot element of the EDXL-SitRep message, containing elements used throughout each individual situation report such as IReport, MessageID, PreparedBy, and IncidentID.
2. A SituationInformation report type identifies and describes the incident with message elements such as IncidentName, IncidentLocation and IncidentType.
3. A FieldObservation report type provides a fast and flexible basic report of an observation in the field by emergency response & management professionals, as a textual description by human parties acting as mobile sensors. This report type is intended for standardized receipt of Field Observations, which may then undergo verification and/or integration into formal Situation Reporting.
4. A CasualtyAndIllnessSummary report type provides counts by responders and non-responders for various categories such as fatalities, missing and hospitalized over specified time periods. These data items may be collected as needed and combined in the manner required for specific reports or for decision making purposes.
5. A ResponseResourcesTotals report type contains responding resources and resource needs to manage and coordinate resource decisions. This report type keeps this information organized together for ease of reference and reuses the EDXL Resource Messaging Elements as needed.
6. A ManagementReportingSummary report type provides for the collection of data related to management concerns such as operational planning, damage and threat assessment, weather conditions, etc. It contains incident organization information where cross-profession or jurisdiction Incident Command structure is in place.
6.1. A SituationSummary package provides supporting information for ManagementReportingSummary or user-defined custom reports.
6.2. A DecisionSupportInformation package likewise provides detailed information supporting the ManagementReportingSummary report type or user-defined custom reports.
7. A Supporting Elements Model package provides the following:
7.1. A CommonTypes Package of elements organized separately to be reused as needed, including. a ValueListTypeInformation subset.
7.2. A ContactInformation Package of elements organized separately to be reused as needed, including the EDXL-CIQ Profile;
7.3. A LocationInformation Package of elements organized separately to be reused as needed including the EDXL-GSF Profile.
Table 1 in Section 3.3 provides a Situation Report Type Summary of the five (5) specific types of Situation Report messages. This provides a quick overview of the message types contained in this standard.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in
this document are to be interpreted as described in [RFC2119].
The term “Conditional” as used in this specification is to be interpreted that a message element MUST be used, according to specified rules, within a particular report message type (elements MUST be one of “Required,” “Optional” or “Conditional”).
[EDXL-SitRep-Rqmts]
DHS
S&T-OIC, EDXL Requirements Statement
and draft Messaging Specification for the Situation Reporting Messaging
Standard (EDXL-SitRep), Version 1.2 http://www.oasis-open.org/committees/download.php/32036/EDXL-SitRep-Rqmts-MsgSpec020209.pdf 2 February 2009.
S. Bradner, Key
words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119,
March 1997. http://www.ietf.org/rfc/rfc2119.txt.
[RFC2046]
N. Freed, Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types, IETF RFC 2046, November 1996. http://www.ietf.org/rfc/rfc2046.txt.
[RFC3066]
H. Alvestrand, Tags for the Identification
of Languages, IETF RFC 3066, January 2001. http://www.ietf.org/rfc/rfc3066.txt.
[WGS 84]
National
Geospatial Intelligence Agency, Department of Defense, World Geodetic System
1984, NGA Technical Report TR8350.2, January 2000. http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf.
[XML 1.0]
T.
Bray, Extensible Markup Language (XML) 1.0 (Third
Edition), W3C REC-XML-20040204, (Fifth Edition), 26 November 2008. http://www.w3.org/TR/REC-xml/.
[namespaces]
T.
Bray, Namespaces in XML, W3C REC-xml-names-19990114, (Third Edition) W3C
Recommendation 8 December 2009. http://www.w3.org/TR/REC-xml-names/.
[dateTime]
N. Freed,
XML Schema Part 2: Datatypes (Second Edition), W3C
REC-xmlschema-2, October 2004. http://www.w3.org/TR/xmlschema-2/#dateTime.
[EDXL-SitRep-Rqmts]
Emergency
Data Exchange Language (EDXL) Requirements Statement and draft Messaging Specification for the Situation
Reporting Messaging Standard (EDXL-SitRep) Version1.2, Prepared by the DHS S&T-OIC EDXL
Messaging Standards Project Team, 2 February 2009. http://www.oasis-open.org/committees/download.php/32036/EDXL-SitRep-Rqmts-MsgSpec020209.pdf.
[EDXL-DE]
Emergency
Data Exchange Language (EDXL) Distribution Element Version 2.0, Edited by
Jeff Waters, 19 Sept. 2013, Committee
Specification CS02. Latest version: http://docs.oasis-open.org/emergency/edxl-de/v2.0/edxl-de-v2.0.html.
[EDXL-HAVE]
Emergency
Data Exchange Language (EDXL) Hospital AVailablity Exchange, Edited by
Sukumar Dwarkanath. 01 November 2008. OASIS Standard OS01. http://docs.oasis-open.org/emergency/edxl-have/os/emergency_edxl_have-1.0-spec-os.html. Latest version: http://docs.oasis-open.org/emergency/edxl-have/v1.0/emergency_edxl_have-1.0.html.
[EDXL-RM]
Emergency Data Exchange Language Resource Messaging (EDXL-RM) 1.0. Edited by Dr. Patti Aymond, Rex Brooks, Tim Grapes, Gary Ham, Dr. Renato Iannella, Dr. Karen Robinson, Werner Joerg, and Alessandro Triglia. 1 November 2008. OASIS Standard OS 01. http://docs.oasis-open.org/emergency/edxl-rm/v1.0/os/EDXL-RM-v1.0-OS.html. Latest version: http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.html.
[EDXL-CT]
Emergency
Data Exchange Language (EDXL) Common Types (CT) Version
1.0. Edited by Werner Joerg, Rex Brooks, Jeff Waters, and Don McGarry. 13
Jan. 2015.Committee Specification Draft CSD03. http://docs.oasis-open.org/emergency/edxl-ct/v1.0/edxl-ct-v1.0.html.
[EDXL-CIQ]
Emergency
Data Exchange Language (EDXL) Customer Information Quality (CIQ)
Profile Version1.0. Edited by Werner Joerg and Jeff Waters. OASIS Committee
Specification Draft CSD04, 13 Jan. 2015. http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/edxl-ciq-v1.0.html.
[EDXL-GSF]
Emergency
Data Exchange Language (EDXL) GML Simple Features Profile Version
1.0, Edited by Werner Joerg and
Lewis Leinenweber. OASIS Committee Specification Draft CSD02, 13 Jan. 2015. http://docs.oasis-open.org/emergency/edxl-gsf/v1.0/edxl-gsf-v1.0.pdf.
[OGC CRS]
Open Geospatial Consortium, Spatial Referencing by Coordinates, CRS Abstract Specification, Topic 2, Version 3, 2004. https://portal.opengeospatial.org/files/?artifact_id=6716,.
[EDXL GFR]
EDXL General Functional Requirements, OASIS Emergency Management TC, 4
November 2004 http://www.oasis-open.org/committees/download.php/10031/EDXL%20General%20Functional%20Requirements.doc,
[EDXL-DE IG]
EDXL
Distribution Element Implementer's Guide, Edited by Patti Aymond, 19 Aug. 2005. OASIS
Working Draft WD01. http://www.oasis-open.org/committees/download.php/14120/EDXL_Implementer%27sGuide.doc
[ISO 4217]
ISO
4217:2001, Codes for the representation of currencies and funds
[ISO 4217 codes]
ISO 4217
currency names and code elements. http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/currency_codes/currency_codes_list-1.htm
[UCUM]
Gunther Schadow, Clement J. McDonald, The
Unified Code for Units of Measure,Version 1.6, http://aurora.regenstrief.org/UCUM/ucum.html,
Regenstrief
Institute for Health Care, 2005.
Below are some
of the guiding principles behind the development of EDXL-SitRep:
·
Provide
a standard message format for the Situation Report
·
Separation
of EDXL-SitRep message structure from routing header structure
·
Provide
separate specific formats for the distinct Situation Report Types in order to
simplify implementation and use
·
Enable
dissemination of messages based on geographic delivery area
·
Use
and reuse of data content and models developed by other initiatives
·
Business
process-driven specific messaging needs across emergency professions
·
Supporting
everyday events and incident preparedness, as well as disasters
·
Facilitate
emergency information sharing and data exchange across the local, state, tribal,
national and non-governmental organizations of different professions that
provide emergency response and management services
The initial requirements submitted to the Technical Committee by the DHS-OIC sponsored EDXL Standards Working Group (SWG) described in Section 1.2 can be reviewed at:
http://www.oasis-open.org/committees/download.php/32036/EDXL-SitRep-Rqmts-MsgSpec020209.pdf
The word processing version of this document can be found at:
http://www.oasis-open.org/committees/download.php/32278/EDXL-SitRep-Rqmts-MsgSpec020209.doc
Note: The following examples of usage scenarios were
used as a basis for development of the practitioner requirements and messaging
specification document which was submitted to OASIS. These scenarios are
non-normative and not intended to be exhaustive or to reflect actual practices.
This scenario
follows the detection of a train derailment either by a GPS system or by a citizen
report via 911/PSAP. An early use case, this specific case illustrated a number
of areas where a clarification of the system needs to be made.
Full use case
available: http://www.oasis-open.org/committees/download.php/32043/EDXL_use_case_Train_Derailv1.5final.doc.
This scenario
includes subsequent developments in a traffic accident and biohazard incident.
Levee Break and
Evacuation with Law Enforcement Focus
The National
Weather Service is reporting that there is no let-up in sight to the rain storm
that has been drenching the area for the last 36 hours. An unprecedented amount of rain has
fallen. A levee next to a local town is
threatening to break.
Estimates of
engineers indicate that the levee will only hold for another 2 hours. This is the time frame in which the initial
response must take place. Emergency
Management has notified local law enforcement: that the 2,000 residents at risk
must be evacuated immediately. 200 are
elderly, of which 50 are non-ambulatory.
Rising water
levels also threaten to cause two major rivers, one flowing through a major
neighboring town to the west, to overflow their banks and cause massive
flooding across the region. These floods
will impact areas of the original town not affected by the impending levee
break.
If these rivers
do overflow their banks, then an additional and much larger number of people
will need to be warned and evacuated.
Full use case
available: http://www.oasis-open.org/committees/download.php/32042/EDXL_use_case_LeveeBreakEvac_v1.1final.doc.
This scenario
takes place in Bayport on a coastal island across a bridge from Fisherville on
the mainland. The nearest large city is
Central City which is 40 miles away and has two hospitals. The first, Faith Hospital, is a regional
cardiac catheterization and care center. Central City Hospital is a level 1
trauma center and operates a medevac helicopter service called Med Flight-1.
Fisherville has a small community hospital with a physician-staffed ER. Fisherville Hospital runs a health clinic in
Bayport, staffed by a physician assistant. The Bayport EMS (BEMS) staff
supports the physician assistant, as well as Central City and Faith Hospital
physicians who have patients in Bayport, by working in the clinic
Full use case
available: http://www.oasis-open.org/committees/download.php/32041/EDXL_use_case_EMS_Callv1.4final.doc.
This scenario
timeline was pieced together using actual documents supporting the “ROAD RESCUE
06 Exercise Plan”, a joint, full scale mass casualty exercise involving
Baltimore County, the private sector and the State of Maryland on March 20,
2006.
Full use case
available: http://www.oasis-open.org/committees/download.php/32040/RoadRescue06ScenarioV1.3final.doc.
This scenario
models an H5N1 Influenza Pandemic outbreak first detected in South China which
then spreads out to global involvement. This use case details the
communications using EDXL, during the various stages or phases of response.
Full use case
available: http://www.oasis-open.org/committees/download.php/32039/Pandemic_Influenza_ScenarioV1.7final.doc
Section 3 of this
Standard is normative unless otherwise stated. If any differences are found
between any XML schema and its associated model, diagram, table or other
artifact or text, then the XML schema shall always take precedence and the
other artifact(s) must be changed to match the XML schema.
Note: Please report any such errors to OASIS.
This section
shows the EDXL–SitRep Element Reference Model (ERM). The purpose of the ERM is
to define the SitRep structure and the relationships between the main entities
and their elements. Using the Unified Modeling Language as a means to
illustrate the relationships, the ERM is not strictly normative. It is important that the ERM is not used as
an implementation model. The exact semantics and structure are captured in the
subsequent sections in the specific predefined EDXL Situation Report Message
Types.
The ERM is
organized into a top level views first and then in groups of related elements
with relationships between those groups and the report type in which they are
used.
The Supporting
Elements Model package is not specifically associated with any report type or
group of elements because these sets of elements are common to all EDXL
messages and may be used in any EDXL SitRep message to which they apply.
The
EDXLSituationReporting XML Schema is provided separately and included in Appendix B. The top level element (<SitRep> aka
<EDXLSitRepRoot>) contains the elements shown in Figure 1. In particular
it contains a report-type dependent element report (<report>) of type
<IReport>. <IReport> is an Abstract Type that serves as the basis for
the five different SitRep report types as shown in Figure 2.
<report xsi:type="FieldObservationType">
Where FieldObservationType references <IReport> as follows:
<xs:complexType
name="FieldObservationType">
<xs:complexContent>
<xs:extension base=”IReport”>
...
</xs:extension>
</xs:complexContent>
</xs:complexType>
Figure
1: SitRep TopLevel Structure
This is explained in more detail in the Data Dictionary Section.
Note: the code above declares the Report type based on <IReport> from
the XML Schema shown below:
<xs:complexType
name="IReport" abstract="true"
<xs:sequence>
<xs:element name=”extension”
type=”ext:ExtensionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
</xs:sequence>
/>
The EDXL Extensions Section elaborates on the “ext:ExtensionType” extension
mechanism of EDXL.
Figure 2: EDXL–SitRep Element Reference Model (ERM) – top level
The SitRep-ERM shows the element-level details for the main entities in
EDXL-SitRep overall. The semantics for each of the elements is defined in Sections 3.3.2 through 3.3.5.
The primary purpose of the Emergency Data Exchange
Language Situation Reporting (EDXL-SitRep) Specification is to provide a set of
standard formats for XML emergency messages containing information pertaining
to the situation with which the message senders and recipients are involved.
These EDXL-SitRep Messages are specifically designed as payloads of the
EDXL-DE. Together EDXL-DE and EDXL-SitRep are intended to expedite activities
associated with reporting on various situation and response activities. As set
forth in Design Principles, routing and distribution information is found only
in the EDXL-DE and not in the EDXL-SitRep.
While the EDXL-SitRep is designed to be an EDXL-DE
payload, other routing mechanisms may be used to distribute EDXL-SitRep content
if the message metadata is provided in the same form or if the sender specifies
specific recipients of the payload.
EDXL Distribution Element (EDXL-DE) V 1.0 was
approved as an OASIS standard in April 2006. The EDXL-DE provides a flexible
message-distribution framework for data sharing among emergency information
systems using XML. The EDXL-DE may be used over any data transmission system,
including, but not limited to, the SOAP HTTP binding.
The primary purpose of the Distribution Element is
to facilitate the routing of emergency messages to recipients. The Distribution
Element may be thought of as a container. It provides the information to route
"payload" message sets by including key routing information such as
distribution type, geography, incident, and sender/recipient IDs. Messages may
be distributed to specific recipients, to recipients in a geographic area, or
based on codes such as agency type (police, fire, etc.).
The following subsections describe practitioner
requirements which are met through the EDXL-Distribution Element (DE).
The Requirement for identifying the “Message Type”
of the EDXL-SitRep is handled by the <distributionType> element of
EDXL-DE v1.0. This is distinct from the “Report Type” of an EDXL-SitRep
message. It is expected that most EDXL-SitRep messages will be of
<distributionType> “Report” shown below.
The <distributionType> element defines the
function of the message and this functional name for the EDXL-SitRep “Message
Type” takes the form of an XML enumeration where the value must be one of:
·
Report - New information
regarding an incident or activity.
·
Update - Updated information
superseding a previous message.
·
Cancel - A cancellation or
revocation of a previous message.
·
Request - A request for
resources, information or action.
·
Response - A response to a
previous request.
·
Ack - Acknowledgment of receipt
of an earlier message.
·
Error - Rejection of an
earlier message (for technical reasons).
It is important to note, as will be detailed later,
that identifying a text message as a “Request” for a Situation Report is
handled by the EDXL <distributionType> element.
The Requirement for identifying the “Message
Sender” of the EDXL-SitRep is handled by one or two elements of EDXL-DE
v1.0.The EDXL-DE v1.0 <senderID> or an element with the identical
definition and properties MUST be present in the EDXL-DE or other routing
mechanism used to distribute an EDXL-SitRep message. The <senderRole> or
an element with the identical definition and properties MAY be present.
<senderRole> is expressed in an XML ValueList
and Value.
·
The list and associated
value(s) is in the form:
<senderRole>
<valueListUrn>valueListUrn</valueListUrn>
<value>value</value>
</senderRole>
·
Where the content of
<valueListUrn> is the Uniform Resource Name of a published list of values
and definitions, and the content of <value> is a string (which may
represent a number) denoting the value itself.
·
Multiple instances of the
<value>, MAY occur with a single <valueListUrn> within the
<senderRole> container.
The EDXL-DE v1.0 <dateTimeSent> element is used
to established the date and time the EDXL-DE package containing the EDXL-SitRep
message is sent.
·
DateTime elements are
represented consistent with previous EDXL standards (24-hour clock):
·
The date and time is
represented in [DateTime] format (e. g., "2008-06-11T16:49:00-07:00"
for 11 June 2008 at 16:49 PDT).
·
Alphabetic time zone
designators such as “Z” MUST NOT be used. The time zone for UTC MUST be
represented as “-00:00” or “+00:00”
The message payload of an EDXL-DE package is a
<contentObject> identified as <xmlContent> with a
<contentDescription> of the EDXL-SitRep Report Type, i.e.
FieldObservation, SituationInformation, ResponseResourcesTotals,
CasualtyAndIllnessSummary or ManagementReportingSummary.
The Requirement to carry multiple SitRep reports /
report types in the same ‘message’ is handled by the the EDXL-DE v1.0, which
can carry multiple content objects. Each <contentObject> MUST be
well-formed <xmlContent>, or <nonXMLContent>. The EDXL-SitRep is
designed to be well-formed XML for routing using the EDXL-DE.
Note: EDXL-DE 2.0 is expected to change the names ‘xmlContent’ and
‘nonXMLContent’.
The Requirement to carry a SitRep “map” or “sketch”
as an object or image is handled by the the EDXL-DE v1.0 <nonXMLContent>
object. The map or sketch may, for
example provide information about the total incident area or total area of
operations.
A graphic representation for the
IncidentCommandStructure detailed in the SitRep may be optionally provided as
an aid to understanding the hierarchy of a given organization’s or agency’s
position roles. This should be provided in the form of a graphic image carried by
the EDXL-DE message header as separate content object.
A digital version of a signature may optionally be
included to provide the authority that authenticates a particular Situation
Report. A digital signature must be
provided in the form of a graphic image carried by the EDXL-DE message header
as separate content object.
The Requirement for identifying the “Sensitivity” or “Releasability” of an
EDXL-SitRep is handled through the EDXL-DE v1.0 elements <Confidentiality>
and <combinedConfidentiality>.
EDXL-DE has a top-level element <combinedConfidentiality> that
indicates the confidentiality of the combined "Content Object"
sub-elements. Generally the combined confidentiality is the most restrictive of
the confidentiality elements in the "Content Object" element, but it
can be more restrictive than any of the individual "Confidentiality"
elements.
The <combindedConfidentiality> element MUST be present if a
"Confidentiality" element is present in any of the “Content Object”
elements.
"Confidentiality" elements are specified in ValueList structures
and are used to meet the EDXL-SitRep requirements for "Sensitivity
Text" approximately equivalent to a set of values like "Top
Secret," "Sensitive, and Classified" and "Sensitive, but
Unclassified."
"Confidentiality" elements are also used to meet the EDXL-SitRep requirements for "Releasability Level" which might also be approximately equivalent to a set of values above, but which might also be different, even within a single jurisdiction. So each jurisdiction should establish its own published ValueLists and policies governing these issues.
Several Element Types, such as incidentStartDateTime, borrow re-usable elements from the
EDXL Common Types that apply to and support multiple areas of the SitRep
messages. For instance incidentStartDateTime relies on the EDXL-CT for a common
date/time format.
The Supporting Elements Model
distinguishes three groups of elements: CommonTypes (EDXL-CT),
Contact Information (EDXL-CIQ) and
Location Information (EDXL-GSF). In this Specification, only the EDXL-CT
elements/types are being used directly; yet some elements in EDXL-CT depend on
EDXL-CIQ (e.g. ct:PersonDetailsType) or on EDXL-GSF (e.g. ct:EDXLLocationType).
The following elements are used in
this specification and can be found at the locations cited in the normative
references in Section 1.6 above.
Supporting
Element/Type |
Defined In |
ct:EDXLDateTimeType |
EDXL-CT (Simple Types) |
ct:EDXLStringType |
EDXL-CT (Simple Types) |
ct:CurrencyType |
EDXL-CT (Simple Types) |
ct:PercentageType |
EDXL-CT (Simple Types) |
ct:RemarksType |
EDXL-CT (Simple Types) |
ct:ValueType |
EDXL-CT (Simple Types) |
ct:EstimateType |
EDXL-CT (Simple Types) |
ct:PersonTimePairType |
EDXL-CT (Complex Types) |
ct:TimePeriodType |
EDXL-CT (Complex Types) |
ct:ValueListType |
EDXL-CT (Complex Types) |
ct:ValueKeyType |
EDXL-CT (Complex Types) |
ct:PersonDetailsType |
EDXL-CT (Complex Types) |
ct:EDXLLocationType |
EDXL-CT (Complex Types) |
ct:WeatherInfoType |
EDXL-CT (Complex Types) |
ct:ValueKeyIntPairType |
EDXL-CT (Complex Types) |
ct:ValueKeyStringPairType |
EDXL-CT (Complex Types) |
ct:ValueListURI |
EDXL-CT (Top Level Elements) |
ext:ExtensionType |
EDXL-EXT |
For a presentation of difference between ValueListType and ValueKeyType, see Appendix C.1: Selecting values from lists.
SitRep supports supplemental
inclusion of community-defined sets of name/value pairs, referred to here as
“Community Extensions” or simply “Extensions” for short. For example, if you
send a DE message with an alert or image about an earthquake, you might want to
include some specific earthquake data, like the magnitude and depth of the
earthquake. There are no earthquake-specific fields in the DE; however, your
community can extend the DE to include that information which you represent as
a set of parameter elements specifically designed to represent earthquake data.
The “Community Extensions” concept solves several major problems for improving
information sharing and developing standards for the emergency management
community. First, the nature of emergencies is that the unexpected will happen
and emergency managers need flexibility to send whatever information is needed.
Second, an emergency begins and often stays local, so local authorities and
users need control to send the information they decide is important to address
the current emergency. Third, communities need the opportunity to explore
potential new standards. The parameter name/value extension mechanism, along
with the registration and best practice guidance, provides an on-ramp for
communities to determine what works well for them. Those Community Extensions
which are most successful can be incorporated formally into future standards.
(For more detail see Appendix C.2: EDXL Extensions).
As further described below, the EDXLSitRepRoot
element is the top level element of the EDXL-SitRep message, containing
elements used throughout each individual situation report. This section
describes the primary components of EDXL-SitRep including the Root element and
the five (5) Report Types.
The SitRep framework is based on a report model. In
this model messages do not expect a Response, although a situation report can
be requested. There is no inherent message exchange protocol represented in
this standard.
A SitRep message MUST be carried as the payload of
the EDXL-DE or any other distribution mechanism that satisfies the DE required
parameters: distribution type values of Report, Update, Cancel, Request,
Response, Ack and Error.
For example, the acknowledgement of a SitRep
message is handled by the distribution mechanism. When a message recipient
receives a SitRep message, it uses the EDXL-DE DistributionType value of “Ack”
as an acknowledgement. An acknowledgement is intended to inform the sender that
the SitRep message has been received.
EDXL-SitRep communication is characterized by two
classes of primary actors An “Incident Command” is an actor that needs or
requires a situation report to undertake response decision(s) during an
incident. An “Incident Command System” is an owner, or distributor, or manager
of situation reports that can meet the needs of Incident Command. These actors
need not belong to the same jurisdiction or organization.
EDXL-SitRep provides five (5) situation report
messages defined in this standard, which are summarized in Table 1 below.
Table 1: Situation Report Message Type Summary--
informative only. It shows how situation reports might flow in incident command
Message Type |
Description |
Message Sender |
FieldObservationType |
Basic report that
describes an observation that is directly observed by the reporter (an
emergency professional). |
On-Scene Incident Command / Planning Section / Situation Unit |
SituationInformationType |
Message used to provide
information on responding resources and resource needs to manage and
coordinate resource decisions. |
On-Scene Incident Command / Planning Section / Situation Unit |
ResponseResourcesTotalsType |
Message used to provide
information on responding resources and resource needs to manage and
coordinate resources. |
On-Scene Incident Command / Logistics Section |
CasualtyAndIllnessSummaryType |
Message used to
summarize information pertaining to the number and status of categorized
casualties and victims of infectious agents associated with the incident. |
Incident Command System/ Logistics Section / Services Unit / Medical Services |
ManagementReportingSummaryType |
Message used to
summarize information and data relevant to ongoing management of incident
response, typically used within the Incident Command Chain or across such
chains between jurisdictions. |
Incident Command System / PIO / Logistics Section / Communications |
Table 2 (below) summarizes all the Message Types
and their element contents, Including the Situation Report Root elements that
can be used in any Message Type. The specific details on each of the Message
Types are outlined in the following sections.
Table 2: Message Element Lists
and Constraints
Table 2.1: Situation Report Root – applies to
all message types
Message
Element |
[ ] |
Message
Element |
[ ] |
Message
Element |
[ ] |
messageID |
1..1 |
preparedBy |
1..1 |
authorizedBy |
1..1 |
reportPurpose |
1..1 |
reportNumber |
1..1 |
reportVersion |
1..1 |
forTimePeriod |
1..1 |
reportTitle |
0..1 |
incidentID |
1..* |
incidentLifecyclePhase |
0..* |
originatingMessageID |
0..1 |
precedingMessageID |
0..* |
urgency |
0..1 |
reportConfidence |
1..1 |
severity |
1..1 |
reportingLocation |
0..1 |
actionPlan |
0..1 |
nextContact |
0..1 |
report |
0..1 |
|
|
|
|
Table
2.2: FieldObservation
Message
Element |
[ ] |
Message
Element |
[ ] |
Message
Element |
[ ] |
observationLocation |
1..1 |
immediateNeeds |
1..1 |
immediateNeedsCategory |
0..* |
observationText |
1..1 |
|
|
|
|
Table 2.3:
SituationInformation
Message
Element |
[ ] |
Message
Element |
[ ] |
Message
Element |
[ ] |
primaryIncidentInformation |
0..1 |
subIncidentInformation |
0..* |
|
|
primaryIncidentInformation / subIncidentInformation |
|||||
incidentName |
1..* |
incidentKind |
0..* |
incidentComplexity |
0..1 |
incidentStartDateTime |
0..1 |
geographicSize |
1..1 |
disasterInformation |
0..* |
incidentLocation |
1..1 |
jurisdictionInformation |
0..* |
incidentStaging |
0..* |
IncidentInformationType.disasterInformation |
|||||
disasterName |
1..1 |
disasterDeclarationAuthority |
1..1 |
disasterDeclarationDateTime |
1..1 |
Note: situationInformation structure is actually a choice:
{{{primaryIncidentInformation [1..1]} {subIncidentInformation [0..*]}} |
{subIncidentInformation [1..*]}} [1..1]
Table
2.4 ResponseResourcesTotals
Message Element |
[ ] |
Message Element |
[ ] |
Message Element |
[ ] |
resourceTotal |
1..* |
organizationAndAssignments |
1..* |
|
|
resourceTotal |
|||||
branchDivisionGroup |
1..1 |
resource |
1..* |
|
|
resourceTotal.resource |
|||||
agencyOrganization |
1..1 |
resourceName |
1..1 |
resourceTypeCategoryKind |
0..1 |
resourceDetail |
0..1 |
isSufficient |
0..1 |
|
|
resourceTotal.resource.resourceDetail |
|||||
resourcePersonnelCount |
0..1 |
unassignedResourcePersonnel |
0..1 |
resourceRequiredCount |
0..1 |
resourceCommittedCount |
0..1 |
resourceOnHandCount |
0..1 |
resourceStillNeededCount |
0..1 |
resourceRequestedCount |
0..1 |
dateTimeOrdered |
0..1 |
requestedArrival |
0..1 |
estimatedArrival |
0..1 |
reportToLocation |
0..1 |
overheadPosition |
0..* |
workAssignment |
0..1 |
specialInstructions |
0..1 |
specialEquipmentAndSupplies |
0..* |
additionalAssistingOrganizations |
0..1 |
resourceStatus |
0..1 |
|
|
resourceTotal.resource.resourceDetail.resourceStatus |
|||||
inventoryRefreshDateTime |
1..1 |
deploymentStatus |
0..1 |
availability |
1..1 |
organizationAndAssignments |
|||||
commandStructure |
0..1 |
positionTitle |
0..1 |
personName |
0..1 |
branch |
0..1 |
reportsToPositionTitle |
0..1 |
reportsToPersonName |
0..1 |
reportsToAgency |
0..* |
reportsToBranch |
0..1 |
|
|
Note: responseResourcesTotals structure is actually a
choice:
{{resourceTotal [1..1]} | {organizationAndAssignments[1..1]}
[1..*]
Table
2.5 CasualtyAndIllnessSummary
Message Element |
[ ] |
Message Element |
[ ] |
Message Element |
[ ] |
summaryCount |
1..* |
notifiableDiseaseNumbers |
1..* |
|
|
summaryCount |
|||||
casualtyAndIllnessCountCategory |
1..1 |
responderSummaryCount |
0..1 |
nonResponderSummaryCount |
0..1 |
responderSummaryCountToDate |
0..1 |
nonResponderSummaryCountToDate |
0..1 |
receivedMassImmunizations |
0..1 |
requireMassImmunizations |
0..1 |
shelterCountEstimate |
0..1 |
|
|
SummaryCount.casualtyAndIllnessCountCategory |
|||||
countCategory |
1..1 |
remarks |
0..1 |
isEstimate |
0..1 |
notifiableDiseaseNumbers |
|||||
diseaseSuspected |
1..1 |
probableCause |
1..1 |
countOfSuspectedCases |
1..1 |
countOfConfirmedCases |
1..1 |
|
|
|
|
Note: casualtyAndIllnessSummary structure is actually a
choice:
{{summaryCount [1..1] | {notifiableDiseaseNumbers [1..1]}}
[1..*]
Table
2.6 ManagementReportingSummary
Message Element |
[ ] |
Message Element |
[ ] |
Message Element |
[ ] |
situationSummary |
1..1 |
decisionSupportInformation |
0..1 |
jurisdictionInformation |
0..* |
situationSummary |
|||||
incidentCause |
1..1 |
significantEvents |
0..* |
damageAssessmentInformation |
0..1 |
primaryHazards |
1..1 |
hazMatIncidentReport |
0..1 |
extentOfContamination |
0..* |
generalPopulationStatus |
0..1 |
externalAffairs |
0..1 |
humanLifeAndSafetyThreat |
0..1 |
lifeAndSafetyThreat |
1..* |
incidentThreatSummaryAndRisk |
0..* |
followOnIndication |
0..1 |
infrastructureAffected |
0..* |
debrisManagement |
0..1 |
propertyDamage |
0..* |
percentContained |
0..1 |
requestsForAdditionalSupport |
0..1 |
terrorismNexus |
0..1 |
weatherEffects |
0..1 |
WMDEffects |
0..1 |
transportationSystems |
0..* |
situationSummary.externalAffairs |
|||||
effectivePublicCommunication |
0..1 |
talkingPoints |
0..1 |
rumors |
0..1 |
situationSummary.debrisManagement |
|||||
totalDebrisGeneratedCY |
0..1 |
debrisClearedToDateCY |
0..1 |
debrisNotYetClearedCY |
0..1 |
daysToClearanceComplete |
0..1 |
percentOfJurisdictionWithDebrisImpacts |
0..1 |
areasWithDebrisImpacts |
0..* |
areasWhereWorkNotStarted |
0..* |
debrisDisposedToDateCY |
0..1 |
debrisNotYetDisposedCY |
0..1 |
debrisStorageSitesPercentFilled |
0..1 |
daysToDisposalComplete |
0..1 |
|
|
situationSummary.propertyDamage |
|||||
numberDamaged |
1..1 |
damageCategory |
1..1 |
|
|
decisionSupportInformation |
|||||
projectedIncidentActivity |
0..1 |
projectedNumberToBeSheltered |
0..1 |
criticalResourceNeeds |
0..* |
projectedFinalIncidentSize |
0..1 |
anticipatedCompletionDate |
0..1 |
projectedDemobilizationStartDate |
0..1 |
estimatedCostsToDate |
0..1 |
projectedFinalCosts |
0..1 |
emergencyResponseIssues |
0..* |
strategicDiscussion |
0..1 |
plannedActions |
0..1 |
|
|
jurisdictionInformation |
|||||
name |
1..1 |
geographicSize |
1..1 |
location |
1..1 |
description |
1..1 |
|
|
|
|
Note: managementReportingSummary structure is actually a
choice:
{{{situationSummary [1..1]} {decisionSupportInformation
[0..1]} {jurisdictionInformation [0..*]}} |
{{decisionSupportInformation [1..1]} {jurisdictionInformation [0..*]}} | {jurisdictionInformation [1..*}}
EDXLSitRepRoot elements are the collection of elements shown in the Element Reference Model below. The SitRepRoot is at the top of SitRep structure. These elements are common to all EDXL-SitRep Report types, and each of these elements can appear in any report. In contrast to the Supporting Element Types which are common, re-usable elements applicable across the Emergency Data Exchange Language standards, SitRepRoot elements are specific to EDXL-Situation Reporting.
Figure 3: EDXLSitRepRoot Elements
It is of particular significance to note the relationship of the <fromDateTime> and <toDateTime> elements to their parent element <ForTimePeriod>. In this case, while both child elements are REQUIRED whenever the parent element is present, the parent element itself is REQUIRED, making the entire ensemble REQUIRED.
The “FieldObservation” report type is used as a basic report that describes an observation that is directly observed by the reporter (an emergency professional), consisting of only four elements.
Figure 4 shows the FieldObservation report type Element Reference Model. The ERM shows the element-level details for the main entities in this fundamental report message type.
The schema for a FieldObservation message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sr/v1.0/os/ and can be found in Appendix B.
Figure 4: EDXLSitRep ERM for FieldObservation Report Type
The “SituationInformation” report message type details the incident to which the current response is being mounted with elements such as incidentName, incidentKind, incidentComplexity and affectedJurisdiction. SituationInformation intends to draw a concise and accurate picture of the situation.
Figure 5 below shows the SituationInformation report type Element Reference Model. The ERM shows the element-level details for the main entities in the SituationInformation report message type.
In addition, there are rules that apply to several elements that should be reviewed in the Message Rules section.
Figure 5: EDXLSitRep ERM for SituationInformation Message
The schema for a SituationInformation message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
The “ResponseResourcesTotals” report type is used to organize and report on the Resources needed or on hand for responding to the current incident.
Figure 6 shows the ResponseResourcesTotals report type Element Reference Model. The ERM shows the element-level details for the main entities in the ResponseResourcesTotals report message type.
The schema for a FieldObservation message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
Figure 6: EDXLSitRep ERM for ResponseResourcesTotals Message
The schema for a ResponseResourcesTotals message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
The “CasualtyAndIllnessSummary” report type is used to present a collection of vital data about the number and kind of casualties resulting from the incident. It is used by Incident Command to assess resource needs related to treating casualties and planning for associated needs such as Field Morgues, Field Hospitals, Temporary Shelters, etc.
Figure 7 below shows the CasualtyAndIllnessSummary report type Element Reference Model. The ERM shows the element-level details for the main entities in the CasualtyAndIllnessSummary report message type.
Figure 7 EDXLSitRep ERM for
CasualtyAndIllnessSummary Message
The schema for a CasualtyAndIllnessSummary message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
The “ManagementReportingSummary” report type is used to compile, organize and report on various aspects of incident management information across responding organizations and up the chain of command.
Figure 8 below shows the ManagementReportingSummary report type Element Reference Model. The ERM shows the element-level details for the main entities in the ManagementReportingSummary report message type.
The schema for a ManagementReportingSummary message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
Figure 8: EDXLSitRep ERM for ManagementReportingSummary
The data dictionary is intended to provide detailed
definition of each element contained in the EDXL-SitRep standard. Where discrepancies may exist between this
dictionary, the Element Reference Model (ERM), and the normative XML, the
normative XML shall take precedence.
·
Element – Name of the element.
·
Type – Type or format of the element.
· Usage – Optionality and Cardinality.
· If no optionality specified, then the element is “Optional”.
·
If no Cardinality specified, the element ”MUST
be used once and only once”
·
Definition – Definition of the element.
·
Comments – Additional comments or
examples to add clarity.
·
Constraints – Limits imposed on the
element. Also notes the container or
“parent” to which the element belongs.
·
Source – Source of the requirement or
usage of the element.
· Requirements Supported – A code representing and referring to each requirement contained in the original submission from the practitioner process to OASIS. EACH general, functional or information requirement is accounted for by one or more elements in the data dictionary, and/or by relationships in the message structure, one or more business rules, or through the overall standard (e.g. for general and functional requirements).
The following list of elements / information requirements
are addressed through the OASIS EDXL-Distribution Element (DE) routing header
(See Section 3.2 of this document for an explanation of each), which is used
for routing and distribution of Situation information as well as other EDXL and
non-EDXL payloads. The EDXL-SitRep standard is designed as a payload requiring
use of a routing header, and specifically designed for use with the
EDXL-Distribution Element (DE). The EDXL-DE is the required
routing/distribution header for EDXL-SitReps unless an alternative routing
header is available which meets all requirements of the EDXL-SitRep standard as
specified in this section, and includes each element required of the EDXL-DE
standard.
EDXL-SitRep
Requirement |
EDXL-DE Element(s) |
Message Type |
DistributionType |
MessageSender |
SenderID and SenderRole |
SensitivityText |
Confidentiality and combinedConfidentiality |
ReleasabilityLevel |
Confidentiality and combinedConfidentiality |
Content Containers |
“XMLcontent” and “nonXMLcontent” containers |
SentDateTime |
dateTimeSent |
Signature |
“nonXMLcontent” containers |
The EDXL-SitRep message consists of a set of core data that are common to all reports and a report specific element named <report> of abstract type <IReport>. <IReport> can be instantiated by any one of the five (5) separate additional data structures, each of which is needed to build one of the five (5) specialized EDXL-SitReps. The schema is provided separately and replicated in Appendix B.
ElementType |
SitRepType |
Type |
xs:complexType |
Definition |
Top level element type of all situation reports |
Comments |
Holds elements common to all report types and a report specific element <report> |
Constraints |
Root element MUST appear once and only once |
Valid Values / Examples |
|
Sub-elements |
·
messageID
[1..1]: ct:EDXLStringType ·
preparedBy
[1..1]: ct:PersonTimePairType ·
authorizedBy
[1..1]: ct:PersonTimePairType ·
reportPurpose
[1..1]: ct:EDXLStringType ·
reportNumber
[1..]: xs:unsignedInt ·
reportVersion
[1..1]: ReportVersionDefaultValues ·
forTimePeriod
[1..1]: ct:TimePeriodType ·
reportTitle
[0..1]: ct:EDXLStringType ·
incidentID
[1..*]: ct:EDXLStringType ·
incidentLifecyclePhase
[0..*]: IncidentLifecycleDefaultValues ·
originatingMessageID
[0..1]: ct:EDXLStringType ·
precedingMessageID
[0..*]: ct:EDXLStringType ·
urgency [0..1]:
UrgencyDefaultValues ·
reportConfidence
[1..1]: ConfidenceDefaultValues ·
severity [1..1]:
SeverityDefaultValues ·
reportingLocation
[0..1]: ct:EDXLLocationType ·
actionPlan
[0..1]: ct:EDXLStringType ·
nextContact
[0..1]: ct:EDXLDateTimeType · report [1..1]: IReport |
Used in |
sitRep |
Requirements
Supported |
SitRep Use Cases |
The <report> element in SitRepType is a placeholder
for report specific data. It is an abstract type that is instantiated by any
one of the five (5) separate additional data structures, each of which is
needed to build one of the five (5) specialized EDXL-SitReps.
<xs:complexType name="IReport"
abstract="true">
<xs:sequence>
<xs:element
name="extension" type="ext:ExtensionType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
This means that <IReport> is not directly used in an
instance document. It is instantiated by a report specific type that extends
the abstract type <IReport> and complements it with report specific, as
shown here:
<xs:element name="Report" type="IReport" minOccurs="1" maxOccurs="1"/>
Report can then be used to declare the Report Type of any
given EDXL-SitRep message as shown here:
<Report xsi:type="FieldObservation">
ElementType |
IReport |
Type |
xs:complexType abstract |
Definition |
Abstract Type used to characterize an EDXL-SitRep message as one of five (5) predefined kinds such as “FieldObservation”. |
Comments |
See section 3.1.1 for diagrammatic representation of the relationship between IReport and Report. |
Constraints |
IReport MUST NOT be used directly in any EDXL-SitRep message of any Report Type. It is part of the XML Schema against which implementations need to be validated. |
Valid Values / Examples |
|
Sub-elements |
Extension [0..*]: ext:ExtensionType |
Used in |
SitRepType |
Requirements
Supported |
Message types |
The five (5) distinct “Reports”, defined in Sections 3.4.2 through 3.4.5, provide a method to componentize the overall EDXL-SitRep standard into logical groups of elements that support a common purpose.
For example, the ’Casualty and Illness Summary’ is focused only on rollup or aggregation of numbers and percentages representing human casualties by categories such as fatalities, hospitalized or missing.
<sitRep> is the top level element of any sitRep message. It contains a set of shared message elements used across the five (5) predefined EDXL-SitRep “Reports”, that convey information such as MessageID, PreparedBy and ForTimePeriod.
Element |
messageID |
Type |
ct:EDXLStringType |
Usage |
REQUIRED [1..1] |
Definition |
Each EDXL-SitRep contains an identifier that uniquely identifies the EDXL-SitRep message / Report. |
Comments |
The EDXL Distribution Element contains the "Distribution ID", which identifies the container for the distribution message information. messageID is the same element as used in EDXL-RM. |
Constraints |
Used in EDXLSitRepRoot element / container |
Part of |
SitRepType |
Source |
SitRep Use Cases, EDXL-RM |
Requirements
Supported |
MessageID |
Element |
preparedBy |
Type |
ct:PersonTimePairType |
Usage |
REQUIRED [1..1] |
Definition |
The person name and/or PositionTitle (ICSPositionTitle when an Incident Management Organization is in place) of the person preparing the information that makes up the message / report and the associated DateTime that this report was prepared |
Comments |
The preparedBy/Reporter/Originator may be different from the sender. Synonyms found in the NIMS SitRep: “Originator”, “Reporter” |
Constraints |
Used in EDXLSitRepRoot element / container |
Part of |
SitRepType |
Source |
ICS-209 |
Requirements
Supported |
Contact-Role-Enumerations, Report-DateTime-Information |
Element |
authorizedBy |
Type |
ct:PersonTimePairType |
Usage |
REQUIRED [1..1] |
Definition |
The person name and/or PositionTitle (ICSPositionTitle when an Incident Management Organziation is in place) of the person formally authorizing the information that makes up the message / report and the associated DateTime that this report was prepared |
Comments |
When an incident Management Organization is in place, this would be the Planning Section Chief or Incident Commander at the incident. On other incidents, it could be the jurisdiction's dispatch center manager, organizational administrator, or other manager. |
Constraints |
Used in EDXLSitRepRoot element / container |
Part of |
SitRepType |
Source |
ICS-209 |
Requirements
Supported |
Contact-Role-Enumerations, Report-DateTime-Information |
Element |
reportPurpose |
Type |
ct:EDXLStringType |
Usage |
REQUIRED [1..1] |
Definition |
States the purpose of this Situation Report. May contain description information regarding why the report is being sent and required response or action, if any. |
Comments |
|
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
Found in some local incident/situation reports. |
Requirements
Supported |
Report Purpose |
Element |
reportNumber |
Type |
ct:EDXLStringType |
Usage |
REQUIRED [1..1] |
Definition |
A unique number for reporting an incident or event, used to identify each new or updated report instance. Used to support report tracking. |
Comments |
EXAMPLE: reportNumber is “12345” reportVersion is “Initial” (of Report # 12345) |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
ICS-209 |
Requirements
Supported |
Report-Number-Version |
Element |
reportVersion |
Type |
ct:ValueType |
Usage |
REQUIRED [1..1] |
Definition |
This
indicates the current version of the specific SitRep MessageReportType report
being submitted from the same source (“authorizedBy”) for the same incident
or event. If only one SitRep will be
submitted, indicate BOTH “Initial” and “Final”. Default value list: ReportVersionDefaultValues |
Comments |
|
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
ICS-209 |
Requirements
Supported |
Report-Number-Version |
Element |
forTimePeriod |
Type |
ct:TimePeriodType |
Usage |
REQUIRED [1..1] |
Definition |
forTimePeriod
designates the period of time between the <fromDateTime> and the
<toDateTime> elements whose definitions immediately follow this element
defninition. forTimePeriod is
used by the <reportNumber> and <reportVersion> elements whose
definitions immediate precede this element definition.. forTimePeriod
SHOULD include all of the time since the last <sitRep>
<reportNumber>/<reportVersion> of this type was submitted. However, if this
report is the originating EDXL-SitRep message for an incident, it should
cover the time lapsed since the incident or event started. The forTimePeriod
element MUST include one operational period, but MAY also include more than
one Operational Period based on agency/organizational reporting
requirements. All elements of information contained in a given EDXL-SitRep message report type always apply only to the forTimePeriod specified by the <fromDateTime> and the <toDateTime>. |
Comments |
|
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
ICS 203, 207, 209, 215 |
Requirements
Supported |
Report-DateTime-Information |
Element |
reportTitle |
Type |
ct:EDXLStringType |
Usage |
OPTIONAL [0..1] |
Definition |
reportTitle is the designation of a more specific title for the SitRep report other than or in addition to the title given as the value of the <sitRep> element. |
Comments |
Used to give a more particular title to an incident |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
ICS-209 |
Requirements
Supported |
Report-Number-Version |
Element |
incidentID |
Type |
ct:EDXLStringType |
Usage |
REQUIRED; MAY be used more than once [1..*] |
Definition |
The name or other identifier of the incident to which the current message refers, that has been assigned to the incident by an authorized agency based on current guidance.The incident number may vary by jurisdiction and profession (e.g. law enforcement vs. Fire). The incident number may be a computer aided dispatch number, an accounting number, a disaster declaration number, or a combination of the state, unit/agency, and dispatch system number. “Unknown” is an acceptable value. |
Comments |
|
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
ICS 209 (“IncidentNumber”) |
Requirements
Supported |
Incident-Identifier |
Element |
incidentLifecyclePhase |
Type |
ct:ValueType |
Usage |
OPTIONAL; MAY be used more than once [0..*] |
Definition |
A code specifying the incident response lifecycle stage currently in effect |
Comments |
|
Constraints |
·
Default value
list: IncidentLifecycleDefaultValues · Used in SitRep “SituationInformation” Report Type |
Part of |
SitRepType |
Source |
|
Requirements
Supported |
IncidentLifecyclePhase |
Element |
originatingMessageID |
Type |
ct:EDXLStringType |
Usage |
OPTIONAL [0..1] |
Definition |
Each EDXL-SitRep message contains a <messageID> that uniquely identifies the message. <originatingMessageID> identifies the <messageID> of the first message in a message sequence to which the message belongs. If the message is itself the originating message in a new sequence, <originatingMessageID> will have the same value as the <messageID> element. In some other cases, the <originatingMessageID> element will have the same value as the <precedingMessageID> element. The <originatingMessageID> value essentially forms a unique identifier for a group of related messages, linking them together so that the relationship between the messages is made explicit and unambiguous (and threads of messages can be tracked by software). |
Comments |
·
Used to keep
track of a string of related SitReps; especially given the fact that
different jurisdictions may refer to the same incident or event in different
ways and even define those different ways. ·
This MessageID
is a SitRep MessageID, not an EDXL-Distribution Element MessageID. ·
Re-uses the same
element as used in EDXL-RM · Should be included if known |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
|
Requirements
Supported |
MessageID |
Element |
precedingMessageID |
Type |
ct:EDXLStringType |
Usage |
OPTIONAL; MAY be used once and only once. [0..*] |
Definition |
The PrecedingMessageID identifies the message that immediately preceded the current message in the message sequence. This messageID is a SitRep <messageID> not an EDXL-Distribution Element MessageID. |
Comments |
·
Typically
SitReps are sequential from a given sender or authoritative source, but
parallel SitReps will occur from several senders or sources. · This is particularly important given the fact that different jurisdictions may refer to the same incident or event in different ways and even define them differently. |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
|
Requirements
Supported |
MessageID |
Element |
urgency |
Type |
ct:ValueType |
Usage |
OPTIONAL [0..1] |
Definition |
The code denoting the importance and necessity of the SitRep message |
Comments |
·
The
<urgency>, <severity> and <reportConfidence> elements
collectively distinguish less
emphatic from more emphatic messages. · Default value list: UrgencyDefaultValues |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
SitRep Use Cases, Common Alerting Protocol (CAP) |
Requirements
Supported |
Urgency |
Element |
reportConfidence |
Type |
ct:ValueType |
Usage |
REQUIRED [1..1] |
Definition |
The code denoting the level of confidence or sureness in the content of the EDXL-SitRep message, endorsed by the officer in the“AuthorizedBy” role. |
Comments |
·
The
<urgency>, <severity> and <reportConfidence> elements
collectively distinguish less emphatic from more emphatic messages. · Default value list: ConfidenceDefaultValues |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
SitRep Use Cases, Common Alerting Protocol (CAP) |
Requirements
Supported |
ReportConfidence |
Element |
severity |
Type |
ct:ValueType |
Usage |
REQUIRED [1..1] |
Definition |
The code denoting the severity of the subject incident or event. |
Comments |
·
The
<urgency>, <severity> and <reportConfidence> elements
collectively distinguish less emphatic from more emphatic messages. ·
Re-uses the same
element as used in EDXL CAP 1.2 · Default value list: SeverityDefaultValues |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
SitRep Use Cases (not found in research, ICS or DHS forms) |
Requirements
Supported |
Severity |
Element |
reportingLocation |
Type |
ct:EDXLLocationType |
Usage |
OPTIONAL [0..1] |
Definition |
A structure representing the physical location and/or organization associated with the <preparedBy> role, or associated with the location where the Field Observation is taking place, i.e. “where I am”. |
Comments |
|
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
|
Requirements
Supported |
Incident-Resource-Operational-Planning,
Incident-Resource-Commitment-Summary |
Element |
actionPlan |
Type |
ct:EDXLStringType |
Usage |
OPTIONAL [0..1] |
Definition |
General description of what the officer in the <preparedBy> role needs or expects, or a description of intended next step(s) of Incident Command. ActionPlan is assumed to relate to the next operational period unless paired with a “StandardTimeFrame” defined by the user. |
Comments |
Synonyms of ActionPlan include “Way Forward,’” “Next Steps,” “Moving On” |
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
National Incident Management System (NIMS) |
Requirements
Supported |
Action-Plan |
Element |
nextContact |
Type |
ct:EDXLDateTimeType |
Usage |
OPTIONAL [0..1] |
Definition |
DateTime of next contact or report planned by the <preparedBy> role to set expectations for provision or receipt of updated or additional information. |
Comments |
|
Constraints |
Used in SitRep element / container |
Part of |
SitRepType |
Source |
NIMS |
Requirements
Supported |
Next-Contact |
Element |
report |
Type |
IReport |
Usage |
REQUIRED; MUST be used once and only once [1..1] |
Definition |
<report> is the element used to create an instance of the IReport abstract type and through it, to specify the EDXL-SitRep Report Type of the message in which it is used. |
Comments |
|
Constraints |
<report> MUST declare
one of the five specific EDXL-SitRep Report Types: ·
fieldObservation
[0..1]: FieldObservationType ·
situationInformation
[0..1]: SituationInformationType ·
responseResourcesTotals
[0..1]: ResponseResourcesTotalsType ·
casualtyAndIllnessSummary
[0..1]: CasualtyAndIllnessSummaryType · managementReportingSummary [0..1]: ManagementReportingSummaryType |
Part of |
SitRepType |
Source |
Used in the SitRep element / container |
Requirements
Supported |
|
The FieldObservation Report provides a basic Report Type intended for fast and flexible observation in the field by emergency response & management professionals, providing a collection of facts usually detected by human parties acting as mobile sensors and presented using plain text. Input sources will generally be mobile phones and other mobile devices.
The purpose of a Field Observation is to offer a standardized method of providing “on the ground” input from responders in the field. The intent is standardized receipt of Field Observations, which then may undergo verification and/or integration into formal Situation Reporting.
ElementType |
FieldObservationType |
Type |
xs: complexType extends IReport |
Definition |
FieldObservation refers to directly observed phenomena in the field reported by the actual witness to the events reported in this EDXL-SitRep report message type. |
Comments |
This
is an intentionally general report type meant to be reported as immediately
and directly as possible. Speculation, even if based
on experience is discouraged in this report type, so discussion of the past
causes and future development are not specifically included. FieldObservation is intended to be quick and brief to expedite the quickest possible appropriate response. |
Constraints |
Used in EDXL-SitRep FieldObservation report type. |
Valid Values / Examples |
|
Sub-elements |
·
observationLocation
[1..1]: ct:EDXLLocationType ·
immediateNeeds
[1..1]: ct:EDXLStringType ·
immediateNeedsCategory
[0..*]: ImmediateNeedsCategoryDefaultValues · observationText[1..1]: xs:string |
Used in |
SitRepType |
Requirements
Supported |
Flexibility |