Additional artifacts:This prose specification is one component of a Work Product that also includes:• XML schemas: http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csprd03/schemas/• Example files: http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csprd03/examples/
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) Version 1.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 Version 1.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:• urn:oasis:names:tc:emergency:EDXL:SitRep:1.0
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 instructionsat 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.
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 befollowed) 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, tonotify 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 producedthis specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of anypatent 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 representthat 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 beused 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.
2 Design Principles and Concepts (Non-normative)................................................................................112.1 Requirements for Design.............................................................................................................112.2 Example Usage Scenarios...........................................................................................................11
2.2.1 Train Derailment Example...................................................................................................112.2.2 Levee Break and Evacuation with Law Enforcement Focus.................................................112.2.3 EMS Call.............................................................................................................................. 122.2.4 Road Rescue -- Highway Incident Scenario & Use Case.....................................................122.2.5 Pandemic Influenza.............................................................................................................12
3 EDXL Situation Reporting Model (Normative unless otherwise stated)................................................133.1 Element Reference Model (Non-normative).................................................................................13
3.1.1 Report Types Instantiate Abstract Type IReport (Non-normative)........................................133.2 Distribution of EDXL-SitRep.........................................................................................................14
3.2.1 EDXL Distribution Element (EDXL-DE)................................................................................143.2.1.1 Identifying SitRep MessageType..................................................................................153.2.1.2 Identifying Message Sender.........................................................................................153.2.1.3 DateTime Message Sent..............................................................................................163.2.1.4 Identifying Situation Report Type.................................................................................163.2.1.5 Multiple Report Types (Content Objects) in the Same ‘Message’................................163.2.1.6 MapSketch BinaryObject..............................................................................................163.2.1.7 IncidentCommandStructureGraphic ............................................................................163.2.1.8 Signature...................................................................................................................... 163.2.1.9 Sensitivity and Releasability.........................................................................................16
3.3 Supporting Elements.................................................................................................................... 173.3.1 Common Types................................................................................................................... 173.3.2 Community Extensions........................................................................................................18
3.4.2.1 Overview..................................................................................................................... 233.4.2.2 Field Observation Element Reference Model (Non-normative)...................................23
3.4.3 SituationInformation Report Type........................................................................................243.4.3.1 Overview...................................................................................................................... 243.4.3.2 SituationInformation Element Reference Model...........................................................24
3.4.4 ResponseResourcesTotals Report Type.............................................................................253.4.4.1 Overview...................................................................................................................... 253.4.4.2 ResponseResourcesTotals Element Reference Model................................................25
3.4.5 CasualtyAndIllnessSummary Report Type...........................................................................273.4.5.1 Overview...................................................................................................................... 273.4.5.2 CasualtyAndIllnessSummary Element Reference Model.............................................27
3.4.6 ManagementReportingSummary Report Type.....................................................................283.4.6.1 Overview...................................................................................................................... 283.4.6.2 ManagementReportingSummary Element Reference Model.......................................28
4 Data Dictionary (Normative)................................................................................................................. 304.1 “Routing Header” Elements..........................................................................................................304.2 EDXL SitRep Top Level Elements...............................................................................................31
4.2.1 IReport Type........................................................................................................................ 314.2.2 Common SitRep Elements...................................................................................................32
4.9 Default Value Lists..................................................................................................................... 1095 Conformance..................................................................................................................................... 119
5.1 Conformance Targets................................................................................................................1195.2 Conformance Summaries for EDXL-SitRep Messages and Producers.....................................1195.3 Conformance as an EDXL-SitRep Message..............................................................................119
5.3.1 EDXL-SitRep Message......................................................................................................1195.4 Conformance as an EDXL-SitRep Message Producer...............................................................120
Appendix A Acknowledgments................................................................................................................121Appendix B EDXL-SituationReporting XML Schema...............................................................................122Appendix C EDXL Special Mechanisms.................................................................................................132
Appendix C.1 Selecting values from lists...........................................................................................132Appendix C.1.1 ValueListType......................................................................................................132Appendix C.1.2 ValueKeyType.....................................................................................................133
Appendix C.2 EDXL Extensions.........................................................................................................133Appendix C.2.1 Community augmentation....................................................................................135Appendix C.2.2 List augmentation................................................................................................135Appendix C.2.3 List replacement..................................................................................................136Appendix C.2.4 List redefinition....................................................................................................136
Appendix D - Examples........................................................................................................................... 138Appendix D.1 ICS209 Web Form Example........................................................................................138
Appendix E Revision History................................................................................................................... 144
1 IntroductionAll text is normative unless otherwise labeled.
1.1 PurposeThe 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.
1.2 HistoryThrough 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 Manage-ment Tools; Office for Interoperability and Compatibility (OIC); and Reconnaissance, Surveillance, and In-vestigative Technologies.
Following voice interoperability programs such as SAFECOM, the OIC’s interoperable messaging stan-dards 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 effec-tive and efficient interoperable data sharing. OIC sponsors the process to facilitate practitioner require-ments for the development of EDXL standards.
EDXL will accomplish this mission through the standardization of specific messages (XML messaging in-terfaces) which facilitate coordination and emergency communication between disparate software applica-tions 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 emer-gency 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 ofcharge.
The OIC-sponsored Practitioner Steering Group (PSG) governance was formalized following publication ofthe 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 asso-ciations and organizations, setting priorities and providing recommendations regarding messaging stan-dards 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 inci-dent 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 andafter-action analysis to identify needed improvements in ongoing preparedness.
1.3 Structure of the EDXL Situation Reporting SpecificationThe 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 forvarious 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.
1.4 TerminologyThe 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”).
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.
[RFC2119]
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 GeodeticSystem 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 draftMessaging 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 November2008. OASIS Standard OS 01. http://docs.oasis-open.org/emergency/edxl-
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,.
1.6 Non-Normative References
[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.
2 Design Principles and Concepts (Non-normative)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
2.1 Requirements for Design
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:
2.2 Example Usage ScenariosNote: 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.
2.2.1 Train Derailment ExampleThis 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.
2.2.2 Levee Break and Evacuation with Law Enforcement FocusLevee 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.
2.2.3 EMS CallThis 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.
2.2.4 Road Rescue -- Highway Incident Scenario & Use CaseThis 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 andthe State of Maryland on March 20, 2006.
Full use case available: http://www.oasis-open.org/committees/download.php/32040/RoadRescue06ScenarioV1.3final.doc.
2.2.5 Pandemic InfluenzaThis 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
3 EDXL Situation Reporting Model (Normative unlessotherwise stated)
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 shallalways take precedence and the other artifact(s) must be changed to match the XML schema.Note: Please report any such errors to OASIS.
3.1 Element Reference Model (Non-normative)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 arecaptured 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.
3.1.1 Report Types Instantiate Abstract Type IReport (Non-normative)
The EDXLSituationReporting XML Schema isprovided separately and included in Appendix B.The top level element (<SitRep> aka<EDXLSitRepRoot>) contains the elements shownin Figure 1. In particular it contains a report-typedependent element report (<report>) of type<IReport>. <IReport> is an Abstract Type thatserves as the basis for the five different SitRepreport types as shown in Figure 2.
<report xsi:type="FieldObservationType">
Where FieldObservationType references<IReport> as follows:
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.
3.2 Distribution of EDXL-SitRepThe 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.
3.2.1 EDXL Distribution Element (EDXL-DE)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
«XSDelem ent»+ im mediateNeeds: ct:EDXLStringT ype+ im mediateNeedsCategory: Im mediateNeedsCategoryDefaul tValues [0..*]+ observationLocation: ct:EDXLLocationType+ observationT ext: string
«XSDcomplexT ype»SituationInformationType
«XSDcomplexType»ResponseResourcesTotalsType
«XSDcom plexT ype»CasualtyAndIllnessSummaryType
«XSDcomplexT ype»ManagementReportingSummaryType
«XSDextension»
«XSDextension»
«XSDextension»
«XSDextension»
«XSDextension»
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-DistributionElement (DE).
3.2.1.1 Identifying SitRep MessageTypeThe 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.
3.2.1.2 Identifying Message SenderThe 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.
3.2.1.3 DateTime Message SentThe 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”
3.2.1.4 Identifying Situation Report TypeThe 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.
3.2.1.5 Multiple Report Types (Content Objects) in the Same ‘Message’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’.
3.2.1.6 MapSketch BinaryObjectThe 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.
3.2.1.7 IncidentCommandStructureGraphic 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. Thisshould be provided in the form of a graphic image carried by the EDXL-DE message header as separate content object.
3.2.1.8 SignatureA 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.
3.2.1.9 Sensitivity and ReleasabilityThe Requirement for identifying the “Sensitivity” or “Releasability” of an EDXL-SitRep is handled through the EDXL-DE v1.0 elements <Confidentiality> and <combinedConfidentiality>.
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.
3.3 Supporting Elements
3.3.1 Common Types
Several Element Types, such as incidentStartDateTime, borrow re-usable elements from the EDXL Com-mon Types that apply to and support multiple areas of the SitRep messages. For instance incidentStart-DateTime 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 norma-tive references in Section 1.6 above.
For a presentation of difference between ValueListType and ValueKeyType, see Appendix C.1: Selecting values from lists.
3.3.2 Community ExtensionsSitRep 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 ele-ments 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 emer-gency 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 im-portant 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. (Formore detail see Appendix C.2: EDXL Extensions).
3.4 Situation Report Root and Report TypesAs 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 theprimary 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. Whena 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. Itshows 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 emer-gency professional).
On-Scene Incident Command / Planning Section / Situation Unit
SituationInformationType
Message used to provide information on re-sponding resources and resource needs to man-age and coordinate resource decisions.
On-Scene Incident Command / Planning Section / Situation Unit
ResponseResourcesTotalsTypeMessage used to provide information on re-sponding resources and resource needs to man-age and coordinate resources.
On-Scene Incident Command / Logis-tics Section
CasualtyAndIllnessSummaryType
Message used to summarize information per-taining to the number and status of categorized casualties and victims of infectious agents asso-ciated with the incident.
Incident Command System/ Logistics Section / Services Unit / Medical Ser-vices
ManagementReportingSummaryType
Message used to summarize information and data relevant to ongoing management of inci-dent response, typically used within the Incident Command Chain or across such chains betweenjurisdictions.
Incident Command System / PIO / Logis-tics Section / Com-munications
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 [ ]
3.4.1 EDXLSitRep Root ElementsEDXLSitRepRoot 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 Reporttypes, 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.
«XSDelement»+ actionPlan: ct:EDXLStringT ype [0 ]+ authorizedBy: ct:PersonT im ePairT ype+ forT im ePeriod: ct:T imePeriodType+ incidentID: ct:EDXLStringT ype+ m essageID: ct:EDXLStringT ype+ nextContact: ct:EDXLDateT im eT ype [0 ]+ orig inatingM essageID: ct:EDXLStringT ype [0 ]+ precedingM essageID: ct:EDXLStringT ype [0]+ preparedBy: ct:PersonT im ePairT ype+ reportingLocation: ct:EDXLLocationT ype [0]+ reportNumber: unsignedInt+ reportPurpose: ct:EDXLStringT ype+ reportT i tle: ct:EDXLStringT ype [0]
«enum eration»ReportVersionDefaultValues
In i tia l Update Final
«enum eration»IncidentLifecycleDefaultValues
Preparedness Response M i tigation Recovery
«enum eration»UrgencyDefaultValues
Im m ediate Expected Future Past Unknown
«enum eration»ConfidenceDefaultValues
HighlyConfident Som ewhatConfident Unsure NoConfidence
«enum eration»SeverityDefaultValues
Extreme Severe M oderate M inor Unknown
+reportVersion
1..1
+incidentLi fecyclePhase
0..*
+urgency 0..1
+report
1..1
+reportConfidence 1..1
+severi ty 1..1
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.
3.4.2 FieldObservation Report Type
3.4.2.1 OverviewThe “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.
3.4.2.2 Field Observation Element Reference Model (Non-normative)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
3.4.3 SituationInformation Report Type
3.4.3.1 OverviewThe “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.
3.4.3.2 SituationInformation Element Reference ModelFigure 5 below shows the SituationInformation report type Element Reference Model. The ERM shows theelement-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.
«X SDelem en t»+ im m edia teNeeds: ct:EDX LS tringT ype+ obse rva tionLoca tion : ct:EDX LLoca tionT ype+ obse rva tionT ext: string
«enum era tion»ImmediateNeedsCategoryDefaultValues
Em ergencyM ed ica lS ervices Fi reAndHaza rdousM a te ria ls Inciden tM anagem en t LawEn fo rcem ent M assCare M ed ica lAndPubl i cHea l th Pub l i cWorks Sea rchAndRescue
+im m edia teNeedsCa tego ry 0 ..*
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.
3.4.4 ResponseResourcesTotals Report Type
3.4.4.1 OverviewThe “ResponseResourcesTotals” report type is used to organize and report on the Resources needed or on hand for responding to the current incident.
3.4.4.2 ResponseResourcesTotals Element Reference ModelFigure 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.
Geophysica l M eteoro logical GeneralEmergency Safety Security RescueAndRecovery Rescue FireSupressionAndRescue Fire M edicalAndPubl icHeal th Heal th Pol lutionAndEnvironmentalHazards Publ icAndPrivateT ransportation T ransport Uti l i tyT elecom municationOtherNonTransportInfrastructure CBRNE
«enum eration»IncidentComplexityDefaultValues
Com plex M oderateCom plex M oderate Low
+incidentStaging0..*
+incidentK ind
0..*
+incidentCom plexi ty
0..1
+geographicSize1..1
+jurisdictionInformation0..*
+geograph icSize1..1
+disasterInform ation
0..*
+subIncident1 ..*
+primaryIncidentInform ation1..1
+subIncidentInform ation
0..*
+subIncidentInform ation
1..*
Figure 6: EDXLSitRep ERM for ResponseResourcesTotals Message
The schema for a ResponseResourcesTotals message is supplied separately at http://docs.oa-sis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
Com pensationCla imsUni tLeader Procurem entUni tLeader T im eUni tLeader CostUnitLeader FinanceAdm inistra tionSectionChief Com m unicationsUni tLeader M edicalUnitLeader FoodUni tLeader ServiceBranchDirector GroundSupportUni tLeader Faci l i tiesUni tDirector Supp lyUni tDirector SupportBranchDirector LogisticsSectionChief StagingAreaM anager OperationsSectionChief Dem obi l izationUnitLeader Docum entationUni tLeader ResourcesUnitLeader S ituationUni tLeader P lann ingSectionChief T echnica lSpecialst Publ i cInform ationOfficer SafetyOfficer Com m unicationsOfficer LiaisonOfficer IncidentCom m ander
+resource 1..*
+deploymentStatus0..1
+resourceDetai l 0..1
+resourceStatus0..1
+reportsToPositionT i tle 0..1
+organizationAndAssignm ents
1..1
+resourceT ota l1..1
1..*
resource needs related to treating casualties and planning for associated needs such as Field Morgues, Field Hospitals, Temporary Shelters, etc.
3.4.5.2 CasualtyAndIllnessSummary Element Reference ModelFigure 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.oa-sis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
Fata l i ties Hospi tal ized With InjuryOrIl lness T rappedOrInNeedOfRescue M issing Evacuated Shel teringInPlace InT emporaryShel ters InQuarantine ReceivedM assImm unizations RequireMassIm munizations
+countCategory1..1
+casual tyAndIl lnessCountCategory1..1
+requireM assIm m unizations0..1
+rece ivedM assIm m unizations0..1
1..*
+summ aryCount1..1
+noti fiab leDiseaseNum bers1..1
3.4.6 ManagementReportingSummary Report Type
3.4.6.1 OverviewThe “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.
3.4.6.2 ManagementReportingSummary Element Reference ModelFigure 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.
RoadClosure M assNoti fica tions Evacua tion Shel terInPlace RoadClosure PowerOu tage T reeDown StrandedVehicle WaterLineBreak WaterShortage Quarantine BridgeCollapse Buil dingColl apse Deaths In juries M assIm m uniza tions CleanupCom plete ResidentRepopulation IncidentCom m andT ransi tion Accom pl ishm en ts
«enum eration»LifeAndSafetyThreatDefaultValues
NoLike lyT hreat Potentia lFutu reT hreat M assNoti fica tionsInProg ress M assNoti fica tionsCom pleted NoEvacua tionsIm m inent PlanningForEvacuation PlanningForShel terInPlace Evacua tionsInProgress Shel terInPlaceInProgress Repopula tion InProgress M assIm m uniza tion InProgress M assIm m uniza tionCom plete QuarantineInProgress
«enum eration»InfrastructureAffectedDefaultValues
M assT ransi t RoadsAndHighways Railway BridgesAndT unnels Seaports Waterways Ai rports Broadcast Power Water Bridges GasLines Nuclea r Condui tsAndRaceways Cabl ingAndPatchPanels PowerAndEnergy Ai rCondi tioning DrinkingWater Sewage Irrigation WasteOrHazardousWaste FloodControl EarthM oni toringAndM easurem entNetworks Postal T e lecom m unicationsPhone T elecom m unicationsM obi le In ternetBackbone PrivateNetwork Sate l l i te Electron icCom m unicati onsNetworks PersonalCom putingServersAndDevices T rainedPersonnel
«enum eration»DamageCategoryDefaultValues
T hreatenedWi thin72Hours Dam aged Destroyed
«enum era tion»EmergencyResponseIssuesDefaultValues
ESF11Agricu ltureAndNatu ra lResources ESF2Com m unications ESF5Em ergencyM anagem ent ESF12Energy ESF15ExternalAffa irs ESF4Firefighti ng ESF7LogisticsM anagem entResourceSupport ESF14LongT erm Com m uni tyRecoveryAndM itiga tion ESF6M assCareHousingAndHum anServices ESF10OilAndHazardousM aterial sResponse ESF8Publ icHealthAndM edicalServices ESF13PublicSafe tyAndSecurity ESF3Publ icWorksAndEngineering ESF9SearchAndRescue ESF1T ransportation
+projectedFinalCosts
0..1
+em ergencyResponseIssues 0 ..*
+antici patedCom ple tionDate0..1
+geographicS ize1..1
+estim a tedCostsT oDate
0..1
+signi fican tEvents 0..*
+pro jectedDem obil i za tionStartDate0..1
+externalAffai rs 0..1
+l i feAndSafe tyT hreat
1..*
+infrastructu reAffected 0..*
+debrisM anagem ent 0..1
+propertyDam age
0..*
+dam ageCategory 1..1
+decisionSupportIn form a tion
0 ..1+decisionSupportInform ation
1..1
+jurisd iction Inform ation0..*
+decisionSupportInform ation1..1
+jurisd ictionIn form ation0 ..*
+jurisd iction Inform ation
1..*
+si tuationSum m ary
1..1
4 Data Dictionary (Normative)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).
4.1 “Routing Header” ElementsThe 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 meetsall 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
4.2 EDXL SitRep Top Level ElementsThe 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
4.2.1 IReport TypeThe <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.
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:
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) prede-fined kinds such as “FieldObservation”.
Comments See section 3.1.1 for diagrammatic representation of the relationship between IReport andReport.
ConstraintsIReport 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 vali-dated.
Valid Values /Examples
Sub-elements Extension [0..*]: ext:ExtensionType
Used in SitRepType
Requirements Sup-ported
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.
4.2.2 Common SitRep Elements<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 mes-sage / Report.
Comments The EDXL Distribution Element contains the "Distribution ID", which identifies the con-tainer for the distribution message information. messageID is the same element as
Constraints Used in EDXLSitRepRoot element / container
Part of SitRepType
Source SitRep Use Cases, EDXL-RM
Requirements Sup-ported
MessageID
Element preparedBy
Type ct:PersonTimePairType
Usage REQUIRED [1..1]
DefinitionThe person name and/or PositionTitle (ICSPositionTitle when an Incident Management Organization is in place) of the person preparing the information that makes up the mes-sage / report and the associated DateTime that this report was prepared
Comments The preparedBy/Reporter/Originator may be different from the sender. Synonyms found inthe NIMS SitRep: “Originator”, “Reporter”
Constraints Used in EDXLSitRepRoot element / container
DefinitionThe 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
CommentsWhen an incident Management Organization is in place, this would be the Planning Sec-tion Chief or Incident Commander at the incident. On other incidents, it could be the juris-diction's dispatch center manager, organizational administrator, or other manager.
Constraints Used in EDXLSitRepRoot element / container
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 Sup-ported
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 Sup-ported
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”.
forTimePeriod designates the period of time between the <fromDateTime> and the <to-DateTime> elements whose definitions immediately follow this element defninition.
forTimePeriod is used by the <reportNumber> and <reportVersion> elements whose defi-nitions 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 require-ments.
All elements of information contained in a given EDXL-SitRep message report type alwaysapply 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 Sup-ported
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
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 Sup-ported
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
Each EDXL-SitRep message contains a <messageID> that uniquely identifies the mes-sage. <originatingMessageID> identifies the <messageID> of the first message in a mes-sage 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 <originatingMes-sageID> value essentially forms a unique identifier for a group of related messages, link-ing them together so that the relationship between the messages is made explicit and un-ambiguous (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 Sup-ported
MessageID
Element precedingMessageID
Type ct:EDXLStringType
Usage OPTIONAL; MAY be used once and only once. [0..*]
DefinitionThe 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.
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 Sup-ported
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 distinguishless 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 Sup-ported
ReportConfidence
Element severity
Type ct:ValueType
Usage REQUIRED [1..1]
Definition The code denoting the severity of the subject incident or event.
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 Sup-ported
Severity
Element reportingLocation
Type ct:EDXLLocationType
Usage OPTIONAL [0..1]
DefinitionA 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 Sup-ported
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 re-late 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”
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 Sup-ported
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:
4.3 FieldObservation Report TypeThe 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 actualwitness 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.
DefinitionA structure and/or textual description representing the physical location of the situation being observed, as opposed to the <reportingLocation> which represents the location of the observer or reporter.
Comments
Constraints Needs the highest degree of accuracy possible given the limitations of the situation.
Definition Description of the situation being observed and reported.
Comments
Constraints
Part of FieldObservationType
Source
Requirements Sup-ported
Coordination-with-EDXL-RM,
Response-Resource-Information
4.4 SituationInformation Report TypeThe SituationInformation Report Type identifies and describes the incident with which the message is concerned.
SituationInformation is also supported by the following re-usable elements found in the Supporting Elements (Section 3.3)
• Remarks
• LocationSize (LocationInformation)
• edxl-gsf [XML Structure] (LocationInformation)
• edxl-ciq [XML Structure] (ContactInformation)
Note: The combination of edxl-gsf & edxl-ciq contain a set of re-usable elements such as ContactDescription, ContactRole, ContactLocation, EDXLLocationType, and AdditionalContactInformation.
ElementType SituationInformationType
Type xs:complexType extends IReport
Definition Identifies and describes the incident with which the message is concerned
Used inSituationInformationType.primaryIncidentInformation,
SubIncidentInformationType
Requirements Sup-ported
Incident-Identifier
Element incidentName
Type xs:string
Usage REQUIRED; MAY be used more than once [1..*]
Definition The name assigned to the incident (often by the Incident Commmander or lead Agency).
Comments
Situation Information MUST carry one or multiple incident names. A formally declared incident may have a name which can change during the incident lifespan. Previous names MUST be carried. In addition, the same incident is sometimes assigned different names by different jurisdictions, organizations or agencies. These multiple incident names MUST be carried.
Constraints Used in SitRep “SituationInformation” Report Type
Definition Information indicating the complexity, complications, level of difficulty or cross-profession /jurisdiction / organization aspects involved in addressing or responding to the incident.
Comments ICS-209 term = “Incident Type or Complexity Level”
Constraints Default value list: IncidentComplexityDefaultValues
Used in SitRep “Situation Information” Report type
Part of IncidentInformationType
Source ICS 209, practitioners
Requirements Sup-ported
Incident-Complexity
Element incidentStartDateTime
Type ct:EDXLDateTimeType
Usage OPTIONAL [0..1]
Definition The Date and Time the Incident started or was first observed.
Comments
Always paired with the element “Estimate” (Boolean) to indicate whether the DateTime is estimated vs. known.
• See Appendix C: Time Elements
Constraints Used in SitRep “Situation Information” element / container
Definition The two-dimensional geographic footprint of the incident measured in meters squared, providing the overall size of the incident in terms of geography.
Comments
May be used with the common element “Estimate” to indicate whether the size is estimated or known.
May be used with the common element “Remarks”
Constraints Used in SitRep “Situation Information” Report Type
Part ofIncidentInformationType,
JurisdictionInformationType
Source
Requirements Sup-ported
Incident-Size
Element incidentLocation
Type ct:EDXLLocationType
Usage REQUIRED [1..1]
DefinitionThe physical location of the incident applying reusable <EDXLLocationType> componentsto express location information using a variety of options including geopolitical (e.g. ad-dresses) and geospatial (e.g. lat/long).
Comments
Constraints Used in SitRep “Situation Information” Report Type.
An XML structure containing the following three required elements:
• disasterName
• disasterDeclarationAuthority
• disasterDeclarationDateTime
disasterInformation provides information about any disaster(s) that are associated with this incident
Comments
Constraints Used in SitRep “SituationInformation” Report Type
Part of IncidentInformationType
Source SitRep Use Cases
Requirements Sup-ported
Incident-Identifer
Element jurisdictionInformation
Type JurisdictionInformationType
Usage REQUIRED; MAY be used more than once (one for each Staging Area) [1..*]
Definition
The physical location of each IncidentStagingArea applying reusable EDXLLocationType-components to express location information using a variety of options including geopoliti-cal (e.g. addresses) and geospatial (e.g. lat/long).
Part of the IncidentStaging XML structure.and always paired with IncidentStagingArea
Comments
Constraints Used in SitRep “Situation Information” Report Type
Usage OPTIONAL; MAY be used more than once (one for each Staging Area) [0..*]
Definition
The physical location of each IncidentStagingArea applying reusable EDXLLocationType components to express location information using a variety of options including geopoliti-cal (e.g. addresses) and geospatial (e.g. lat/long).
Part of the IncidentStaging XML structure; always paired with IncidentStagingArea
Comments
Constraints Used in SitRep “Situation Information” Report Type
DefinitionThe Date and Time a formal disaster is declared by an authority
Comments
Constraints Used in SitRep “Situation Information” Report Type
Part of DisasterInformationType
Source SitRep Use Cases
Requirements Sup-ported
Report-DateTime-Information
4.5 ResponseResourcesTotals Report TypeThe ResponseResourcesTotals Report Type contains elements to identify resource needs and resources to meet those needs. These elements are used to manage and coordinate resource decisions. For each Resource “TypeCategoryKind” a “Count” MUST be present.
Elements from the following EDXL-RM container elements MAY be used as input to ResponseResourcesTotals Report Types.
• Resource
• Ownership Information
• Resource Information
• Schedule Information with all ScheduleTypes
• Assignment Information
• Assignment Instructions
Response Resource contains zero to many ResponseResource Elements of Type ResponseResourceType
For each ResponseResource element of Type ResponseResourceType, one and only one of each ResponseResourceDetail Element of Type ResponseResourceDetailType is allowed.
Counts contained in the Response Resource Detail are provided for each Resource / Resource Type/Category/Kind supplied by an agency within a Branch, Division or Group.
EXAMPLE: The following provides a partial example of resource counts (and totals), but does not include all elements. Note that EDXL-SitRep carries resource count information; however totals are not carried bythis structure. Totals are to be calculated by end applications.
DefinitionName of an Incident Command Branch, Division, or Group, or their leadership title or name, or the name of a location (such as a “staging area”) committing each Type / Cate-gory or Kind of resource
The Agency or Organization contributing the resource(s) to the incident, perhaps through mutual aid agreements.
An agency is a type of organization, which is a division of government with a specific func-tion, or a nongovernmental organization (e.g., private contractor, business, etc.) that offersa particular kind of assistance. In ICS, agencies are defined as jurisdictional (having statutory responsibility for incident mitigation) or assisting and/or cooperating (providing resources and/or assistance)
Comments Supported by the edxl-ciq [XML Structure]
Constraints Used in EDXL-SitRep ResponseResourcesTotals Report Type
Similar resources my be grouped together for this purpose (for example, do not list every type of fire engine –rather, it may be advisable to list two generalized types of engines, such as “structure fire engines” and “wildland fire engines” with totals for each).
Examples:
– Fixed wing cargo aircraft
– Mobile Field Kitchen / Type II / Food & Water
– “Decontamination” unit
– Type 1 Fire Engine
– Type 4 Helicopter
Constraints Used in EDXL-SitRep ResponseResourcesTotals Report Type.
Part of ResourceCountType
Source ICS 209
Requirements Sup-ported
Response Resources-Information
Element resourceDetail
Type ResourceDetailType
Usage OPTIONAL; may be used once and only once [0..1]
Definition Summary information, often rendered in “counts” about resources involved in emergency operations.
Comments
Constraints
Part of ResourceCountType
Source
Requirements Sup-ported
Response Resources-Information
Element isSufficient
Type xs:boolean
Usage OPTIONAL; may be used once and only once [0..1]
Definition A “yes” or “no” value indicating whether or not a given resource is sufficient to fill current or projected requirements.
Usage OPTIONAL; may be used once and only once [0..1]
Definition The number of additional individuals (or individuals on overhead) that are not assigned to a specific resource by agency or organization.
Comments
Constraints Used in EDXL-SitRep ResponseResourcesTotals Report Type
Part of ResourceDetailType
Source
Requirements Sup-ported
Incident-Resource-Commitment-Summary
Element resourceRequiredCount
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition The number of resources by “Type/Category/Kind” provided by an “Agency or Organiza-tion”, required to meet a specified need or work assignment.
Comments
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Usage OPTIONAL; may be used once and only once [0..1]
Definition
The number of resources by “Type/Category/Kind” provided by an “Agency or Organiza-tion”, committed to meet the specified need or work assignment. “Committed” refers to anobligation or confirmation from the resource supplier that resource has been allocated to this resource request or order, but has not yet been provided and is not yet “on-hand”.
Comments EDXL-RM message data may be used to provide transaction information which may be totaled to calculate this count
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Part of ResourceDetailType
Source ICS 209
Requirements Sup-ported
Incident-Resource-Commitment-Summary
Element resourceOnHandCount
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition
The number of resources by “Type/Category/Kind” provided by an “Agency or Organiza-tion”, currently on-hand to meet the specified need or work assignment. “On-hand” refers to a resource that has been provided, has arrived and is available on site to meet the specified need or work assignment.
Comments
Some ICS forms refer to this as “Resources-Have”
EDXL-RM message data may be used to provide transaction information which may be totaled to calculate this count
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Part of ResourceDetailType
Source ICS 215
Requirements Sup-ported
Incident-Resource-Operational-Planning
Element resourceStillNeededCount
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
DefinitionThe number of resources by “Type/Category/Kind” provided by an “Agency or Organiza-tion”, still needed to meet a specified need or work assignment. “Needed” refers to re-sources that may or may not be requested or committed; but are not yet “on-hand”
Comments Defined as “ResourceOnHandCount” subtracted from the “ResourceCommittedCount”
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Part of ResourceDetailType
Source ICS 215
Requirements Sup-ported
Incident-Resource-Operational-Planning
Element resourceRequestedCount
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
DefinitionThe number of resources by “Type/Category/Kind” provided by an “Agency or Organiza-tion”, that has been requested or ordered in order to meet a specified need or work as-signment.
Comments EDXL-RM message data may be used to provide transaction information which may be totaled to calculate this count
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Part of ResourceDetailType
Source ICS 215
Requirements Sup-ported
Incident-Resource-Operational-Planning
Element dateTimeOrdered
Type ct:EDXLDateTimeType
Usage OPTIONAL; may be used once and only once [0..1]
Definition The Date/Time that the resource was requested or ordered in order to fill the specified need or work assignment.
Comments
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Comments EDXL-RM message data may be used to provide ReportToLocation information (See EDXL-RM “ScheduleInformation” Element).
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Part of ResourceDetailType
Source ICS 215
Requirements Sup-ported
Incident-Resource-Operational-Planning
Element overheadPosition
Type ct:ValueKeyIntPairType
Usage OPTIONAL; may be used more than once [0..*]
Definition
This element provides a list (ValueKey: xsd:AnyURI) of OverheadPosition (s), each associated with a value (a string in this case to provide a count-integer).
An “OverheadPosition’ is a resource with a role or position (or a group of resources with the same role or position) that is not assigned to or associated with any previously identified Resource
Comments
Overhead Position Examples:
• Division Supervisor
• Group Supervisor
• Assistant Safety Officer
• Technical Specialst
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Part of ResourceDetailType
Source ICS 215
Requirements Sup-ported
Incident-Resource-Operational-Planning
Element workAssignment
Type ct:EDXLStringType
Usage OPTIONAL; may be used once and only once [0..1]
Definition Description of the anticipated work assignments given to the resource
Definition For each “Branch/Division/Group/Location” / “WorkAssignment/SpecialInstructions” com-bination, a listing of special equipment or supplies needed.
Comments
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Usage OPTIONAL; may be used once and only once [0..1]
DefinitionA list of all other agencies and organizations that are not included in the formal “Respon-seResource” information (who are not directly involved in the incident, but are providing support.)
Comments
Examples may include ambulance services, Red Cross, DHS, utility companies.
Do not repeat any resources / organizations listed in the “Incident Resource Commitment Summary”.
Constraints Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Part of ResourceDetailType
Source ICS 209
Requirements Sup-ported
Incident-Resource-Commitment-Summary
Element resourceStatus
Type ResourceStatusType
Usage OPTIONAL; may be used once and only once [0..1]
Definition Availability provides information on whether or not a resource is available, and any inci-dental information not otherwise provided that relates to resource availability.
Incident Organization & Assignments is a component of the “ResponseResourcesTotals” ReportType, providing a hierarchical XML organization structure including information on the names, titles, assign-ments, organization structure and contact information when an incident Command Structure is put into place (i.e. “who’s in charge of what”).
The purpose is to provide a standard structure with which to carry the Positions, Names, Agency, Branch, and “Report-To” relationships required to share incident organization information as needed across agen-cies and up the chain of command, such that end applications may if desired create or populate an inci-dent command structure chart.
Note that an actual graphic representing the pictorial representation of the Incident Organization Chart may be carried using a content object within the EDXL-Distribution element, whether produced from the SitRep organization data or produced by other means.Incident Organization information is also supported by the following re-usable elements associated with the appropriate element:
Used in ResponseResourcesTotalsType.organizationAndAssignments
Requirements Sup-ported
Element commandStructure
Type ct:EDXLString
Usage OPTIONAL; may be used once and only once [0..1]
Definition
A name given to the top level of the organization structure of an Incident Command Structure (also referred to as an “Incident Management Organization and “Unified Com-mand”), when such an organization is in place in response to a large and/or complicated incident requiring cross-profession and jurisdiction coordination. This name typically con-tains reference to the incident or disaster name.
The overall structure contains the Positions, Names, Agency, Branch, and “Report-To” re-lationships required to share incident organization information as needed across agenciesand up the chain of command, such that end applications may if desired create or popu-late an incident command structure chart.
Incident Command structure and personnel may change over the course of an incident, orshifts may transition in/out of active incident management roles.
Comments
Uses edxl-ciq [XML Structure]
The SitRepRoot contains common elements such as sentDateTime and forTimePeriod which is associated with an Incident CommandStructure
Usage OPTIONAL; may be used once and only once [0..1]
Definition Container for person name details
Comments Same person with many types (e.g. alias, pet name, nick name) of names can be used by this container.
Constraints
Part of OrganizationAndAssignmentsType
Source ICS 201, ICS 203
Requirements Sup-ported
Incident-Command-Organization
Element branch
Type ct:ValueKeyType
Usage OPTIONAL; may be used once and only once [0..1]
Definition
The organizational level having functional or geographic responsibility for major parts of incident operations. The Branch level is organizationally between Section and Division/Group in the Operations Section, and between Section and Units in the Logistics Section. Branches are identified by the use of Roman Numerals or by functional name (e.g. medical, security, etc.).
An agency is a type of organization, which is a division of government with a specific func-tion, or a nongovernmental organization (e.g., private contractor, business, etc.) that offersa particular kind of assistance. In ICS, agencies are defined as jurisdictional (having statutory responsibility for incident mitigation) or assisting and/or cooperating (providing resources and/or assistance). (See Assisting Agency, Cooperating Agency, and Mul-ti-agency.)
Comments
Constraints
Part of OrganizationAndAssignmentsType
Source ICS 201, ICS 203
Requirements Sup-ported
Incident-Command-Organization
Element reportsToBranch
Type ct:ValueKeyType
Usage OPTIONAL; may be used once and only once [0..1]
Definition
The organizational level having functional or geographic responsibility for major parts of incident operations. The Branch level is organizationally between Section and Division/Group in the Operations Section, and between Section and Units in the Logistics Section. Branches are identified by the use of Roman Numerals or by functional name (e.g. medical, security, etc.)
Comments
Constraints
Part of OrganizationAndAssignmentsType
Source ICS 201, ICS 203
Requirements Sup-ported
Incident-Command-Organization
4.6 CasualtyAndIllnessSummary Report Type
The “Casualty and Illness Summary” Report Type provides casualty numbers and percentages by pre-scribed categories over specified time periods. Casualty information categories are further segregated byresponders (per the NIMS definition) and non-responders (members of the public). Fatality information or responder status information MUST be actual, and never estimated.Note: In regard to “Totals”, totals can be calculated, so separate elements for those values are not in-cluded
Each Casualty and Illness Category value (except “#Fatalities”) may be paired with the element “Estimate”(Boolean) to indicate whether the Casualty figure is estimated vs. known / actual.
The example below provides a possible application report which may be developed by an application or system. Although this example shows totals and percentages for illustration, only the raw data counts are carried using this standard.
The example illustrates a list of Casualty and Illness Categories which were selected, including for each the Responder Summary Count and Non-Responder Summary Count for This Reporting Period, and the same for Total Number to Date.
Non-normative example
Number This Reporting Pe-riod
Total Number To Date
Casualty & Illness Summary Cate-gories
ResponderSummary Count
Non-Re-sponder Summary Count
TotalThis
Period
Responder Summary Count
Non-Re-sponder Summary Count
Total toDate
NumberOfFatalities 1 1 1 2 3NumberOfHospitalized 0 2 2 4NumberOfWithInjury/Illness 0 6 6NumberOfTrapped/In need of res-cue 0 0NumberOfMissing 0 2 2 4NumberOfEvacuated 0 0NumberOfSheltering In Place 0 0NumberInTemporaryShelters 0 0NumberInQuarantine 0 0HaveReceivedMassImmunization-sCount 0 0RequireMassImmunizationsCount 0 0
TOTAL 1 0 1 5 12 17
Responder Summary Percentage: 100.00% 29.41%
Totalnumber
of casual-ties af-fected
Non-Responder Summary Per-centage: 0.00% 70.59%
Remarks:
ElementType CasualtyAndIllnessSummaryType
Type xs:complexType extends IReport
Definition
CommentscasualtyAndIllnessSummary structure is a choice:
Used in CasualtyAndIllnessSummaryType.summaryCount
Requirements Sup-ported
The CasualtyAndIllnessSummary Report Type as a whole is optional. However, if any one or more ele-ments from the CasualtyAndIllnessSummary Element Group is completed, then a full report MUST be cre-ated and transmitted to the appropriate recipient(s) with roll up to summary numbers “by period”.Summary statistics / totals are broken out by Responders, Non-Responders and overall total.
A type of casualty or illness, used to collect counts and statistics by types of casualties.
Part of the CasualtyAndIllnessSummaryCount XML structure.
Default value list: CasualtyAndIllnessCountCategoryDefaultValues
Comments A casualty is any person impacted in some way by an emergency situation or disaster.
Constraints
Part of CasualtyAndIllnessCountCategoryType
Source ICS 209
Requirements Sup-ported
Casualty-and-Illness-Summary
Element responderSummaryCount
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition
For each casualtyAndIllnessCountCategory, the count of Responder Casualties for this re-porting period.
Part of the casualtyAndIllnessSummaryCount XML structure.
Comments
“Responders” are those personnel belonging to organizations and agencies officially assisting and cooperating with response efforts, and may be included as part of unified command partnerships. Responders may include both paid professionals and volunteer personnel who have recognized emergency response authority at the time of the incident, such as a firefighter, EMT, police officer or Incident Commander.
Constraints Used in EDXL-SitRep “CasualtyAndIllnessSummary” Report Type
Part of SummaryCountType
Source ICS 209
Requirements Sup-ported
Casualty-and-Illness-Summary
Element nonResponderSummaryCount
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition
For each casualtyAndIllnessCountCategory, the count of Non-Responder Casualties for this reporting period.
Part of the CasualtyAndIllnessCountCategoryType XML structure.
Comments “Non-Responders” are those civilians who are affected by the incident, but who are not in-
cluded as part of the authorized response effort (are not categorized as “Responders”.)
Constraints Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Part of SummaryCountType
Source ICS 209
Requirements Sup-ported
Casualty-and-Illness-Summary
Element responderSummaryCountToDate
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition
For each CasualtyAndIllnessCountCategory, the count of Non-Responder Casualties for this incident to date.
Part of the CasualtyAndIllnessCountCategoryType XML structure.
Comments
“Non-Responders” are those civilians who are affected by the incident, but who are not included as part of the authorized response effort (are not categorized as “Responders”.)
E.g. the NumberOfFatalities for this reporting period is 1; however the NumberOfFatalities totaled to date is 3
Constraints Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Part of SummaryCountType
Source ICS 209
Requirements Sup-ported
Casualty-and-Illness-Summary
Element nonResponderSummaryCountToDate
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition
For each CasualtyAndIllnessCountCategory, the count of Non-Responder Casualties for this incident to date.
Part of the CasualtyAndIllnessSummaryCount XML structure.
Comments
“Non-Responders” are those civilians who are affected by the incident, but who are not included as part of the authorized response effort (are not categorized as “Responders”.)
E.g. the NumberOfFatalities for this reporting period is 1; however the NumberOfFatalities totaled to date is 3
Constraints Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Definition The number count of people who have received immunizations relevant specifically to in-cident conditions and/or as part of incident operations.
Comments This number is not included in any Casualty and Illness Summary totals
Constraints Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Definition The number of people who require immunizations relevant specifically to incident conditions and/or as part of incident operations.
Comments Count in this element refers to number of people.
Constraints Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Part of SummaryCountType
Source ICS 209
Requirements Sup-ported
Casualty-and-Illness-Summary
Element shelterCountEstimate
Type xs:unsignedInt
Usage OPTIONAL [0..1]
Definition The total number of people projected to require shelter due to the incident, to assist plan-ning and matching of resources.
Comments This number is not included in any Casualty and Illness Summary totals
Constraints Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Part of SummaryCountType
Source ICS 209
Requirements Sup-ported
Casualty-and-Illness-Summary
4.6.2 NotifiableDiseaseNumbers Complex Type
A notifiable disease is one for which regular, frequent, timely information on individual cases is considerednecessary to prevent and control that disease.
Used in CasualtyAndIllnessSummaryType.notifiableDiseaseNumbers
Requirements Sup-ported
Element diseaseSuspected
Type ct:ValueKeyType
Usage REQUIRED [1..1]
Definition
A notifiable disease is one for which regular, frequent, timely information on individual cases is considered necessary to prevent and control that disease. The list of notifiable diseases varies over time and by state. The list of nationally notifiable diseases is re-viewed and modified by the Council of State and Territorial Epidemiologists (CSTE) and CDC once each year and is available on the Internet at:http://www.cdc.gov/ncphi/disss/nndss/phs/infdis.htm
Comments
Constraints Used in EDXL-SitRep NotifiableDiseaseNumbers element group within the EDXL-SitRep CasualtyAndIllnessSummary Report Type
Part of NotifiableDiseaseNumbersType
Source
Requirements Sup-ported
Notifiable-Disease-Numbers
Element probableCause
Type ct:EDXLStringType
Usage REQUIRED [1..1]
Definition Description of the most likely cause of the suspected disease.
Comments
Constraints Used in EDXL-SitRep NotifiableDiseaseNumbers element group within the EDXL-SitRep CasualtyAndIllnessSummary Report Type
Definition The number of cases alleged but not confirmed of the suspected disease.
Comments
Constraints Used in EDXL-SitRep NotifiableDiseaseNumbers element group within the EDXL-SitRep CasualtyAndIllnessSummary Report Type
Part of NotifiableDiseaseNumbersType
Source
Requirements Sup-ported
Notifiable-Disease-Numbers
Element countOfConfirmedCases
Type xs:unsignedInt
Usage REQUIRED [1..1]
Definition The number of cases officially confirmed of the suspected disease
Comments
Constraints Used in EDXL-SitRep NotifiableDiseaseNumbers element group within the EDXL-SitRep CasualtyAndIllnessSummary Report Type
Part of NotifiableDiseaseNumbersType
Source
Requirements Sup-ported
Notifiable-Disease-Numbers
4.7 ManagementReportingSummary Report Type
The ManagementReportingSummary Report Type contains elements to manage information related to sit-uation information such as property categories, damage assessments, transportation systems, hazards, weather concerns and general threats to the life and property. It has many areas of concern that overlap the other topical categories of situation information, response resources and casualty information related to overall population health.
The foregoing topical categories fall in the SituationSummary Element Group, while the information more directly related to making decisions is gathered into IncidentDecisionSupportInformation Element Group.
This group contains.elements such as ProjectedIncidentActivity, StrategicDiscussion, PlannedActions.
ElementType ManagementReportingSummaryType
Type xs:complexType extends IReport
Definition
The element group gathered in SituationSummary identifies situation status and descrbesinformation aimed, primarily as support for human decision-making across the organiza-tions involved and within the chain of command .
SituationSummary focuses on information about infrastructure and Primary Hazards, Threat to Human Life and Safety, Infrastructure Affected and Possible Cascading Effects.
The element group gathered in SituationSummary identifies situation status and describesinformation aimed, primarily as support for human decision-making across the organiza-tions involved and within the chain of command .
SituationSummary focuses on information about infrastructure and Primary Hazards, Threat to Human Life and Safety, Infrastructure Affected and Possible Cascading Effects.
Usage OPTIONAL; may be used once and only once [0..1]
Definition
DecisionSupportInformation provides information pertaining to decisions required in as timely a fashion as possible. Such information needs to be gathered, assembled and pre-sented to incident command with as much analysis as time allows throughout the lifecycleof the incident and response.
Comments
Constraints
Part of ManagementReportingSummaryType
Source
Requirements Sup-ported
Incident-Response-Information
Element jurisdictionInformation
Type JurisdictionInformationType
Usage OPTIONAL; may be used more than once [0..*]
DefinitionJurisdictionInformation provides key information about incident command and the various organizations involved in the response. Jurisdiction Information is key to making quick decisions that do not exceed the authority of the jurisdiction involved
Comments
Constraints
Part ofManagementReportingSummaryType,
IncidentInformationType
Source
Requirements Sup-ported
Incident-Response-Information
4.7.1 SituationSummary Complex TypeThe SituationSummary element group provides concise status and descriptive information about the overall situation, primarily as input to human decision-making across coordinating organizations and up the chain of command . SituationSummary focuses on information about the current situation affecting people and infrastructure safety such as Primary Hazards, Threat to Human Life and Safety, InfrastructureAffected and Possible Cascading Effects.
Definition The known or suspected cause of the incident such as "tornado", "wildfire", "bridge col-lapse", "parade", "vehicle fire", "mass casualty", etc.
Comments May be used with the common element “Estimate” to indicate whether the size is estimated or known
Constraints
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information Information Requirement #28
Element significantEvents
Type ct:ValueType
Usage OPTIONAL; may be used more than once [0..*]
Definition
This element provides a list (ValueKey: xsd:AnyURI) of SignificantEvent(s), each associ-ated with a value. The value is a string providing a textual description summarizing signifi-cant results, decisions or progress resulting from an incident such as, evacuations, inci-dent growth, etc. during the period being reported (“ForTimePeriod”). For example, road closures, evacuations, progress made, accomplishments, incident command transitions, repopulation of formerly evacuated areas, etc. Includes specifics, for example road clo-sures include road number and duration of closure.
Default value list: SignificantEventsDefaultValues
Comments Re-uses the element “Remarks” to include specifics
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information
Element damageAssessmentInformation
Type xs:string
Usage OPTIONAL; may be used once and only once [0..1]
DefinitionTextual description summarizing damage and/or restriction of use/availability to residentialor commercial property, natural resources, critical infrastructure and key resources, etc. Includes a short summary of damage or use or access restrictions caused by the incident.
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information
Element primaryHazards
Type xs:string
Usage OPTIONAL; may be used once and only once [0..1]
Definition
Textual description summarizing hazardous chemicals, fuel types, infectious agents, radi-ation, etc. When relevant includes the appropriate primary materials, fuels or other haz-ards involved in the incident that are leaking, burning, infecting or otherwise causing majorproblems. Examples include hazardous chemicals, wildland fuel models, biohazards, ex-plosive materials, oil, gas etc.
Comments
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information
Element hazMatIncidentReport
Type xs:any
Usage OPTIONAL; may be used once and only once [0..1]
Definition
This element provides a brief overall HazMat summary, providing an XML structure which fulfills the information needs contained in “HazMat* Incident Report Form 5800.1 (DOT – IEEE 1512)”. IEEE 1512 may be used as well as other namespaced existing standards
DefinitionInformation about concerns that are external to the managementReportingSummary con-text that nevertheless needs to be taken into account by the responder organizations and jurisdictions
Comments
Constraints
Part of SituationSummaryType
Source
Requirements Sup-ported
Element humanLifeAndSafetyThreat
Type xs:string
Usage OPTIONAL; may be used once and only once [0..1]
Definition Textual description of hazards which are potentially dangerous and cause a threat to hu-man life and safety
Comments
This element reflected in the similar “LifeAndSafetyThreat” element in the IncidentDecisionSupportInformation element group.
This is a textual element in SituationSummary element group that is reflected by a more structural, decision-oriented version of essentially the same kind of data.
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information
Element lifeAndSafetyThreat
Type ct:ValueType
Usage REQUIRED; may be used more than once [1..*]
Definition A code indicating the current state of the threat and actions taken to manage it.
Comments
Ensure not duplicate with Situation Summary info, or ensure consistent terminology which differentiates.
Re-uses the element “Remarks” to include notes related to each code.
This element is reflected by “humanLifeAndSafetyThreat” element in the “situationSummary” element group
Default value list: LifeAndSafetyThreatDefaultValues
Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Incident-Decision-Support-Information
Element incidentThreatSummaryAndRisk
Type xs:string
Usage OPTIONAL; may be used more than once [0..*]
DefinitionA summary of the current threat and risk potential, movement, escalation, or spread over 12-, 24-, 48- and 72-hour standard time frames represented in the “StandardTimeFrames”common type, and any threat or risk anticipated after 72-hours.
CommentsNote: See EAS time frames also for potential adoption / reuse
Used in conjunction with the “StandardTimeFrames” element (ValueListURN).
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Incident-Decision-Support-Information
Element followOnIndication
Type xs:string
Usage OPTIONAL; may be used once and only once [0..1]
Definition Textual description of known or anticipated incidents that will or may happen as a result of, or otherwise immediately following, the current incident
Comments
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Usage OPTIONAL; may be used once and only once [0..1]
Definition Textual description of any connections that may exist with terrorist acts associated with this incident.
Comments
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source
Requirements Sup-ported
Situation-Summary-Information
Element weatherEffects
Type ct:WeatherInfoType
Usage OPTIONAL; may be used once and only once [0..1]
DefinitionText indicating Current and predicted weather and related factors that may effect or causeconcern for the incident and related areas, in the form of a short synopsis on weather fac-tors.
Comments
Always paired with Weather Concerns
Includes current and/or predicted weather factors, and the time frame for predictions. Includes relevant factors listed below and other weather information relative to the incident, such as flooding, hurricanes, etc.
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information
Element WMDEffects
Type xs:string
Usage OPTIONAL; may be used once and only once [0..1]
Definition Textual descripton of any effects produced by weapons of mass destruction.
Constraints Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source
Requirements Sup-ported
Situation-Summary-Information
Element transportationSystems
Type ct:ValueKeyStringPairType
Usage OPTIONAL; may be used more than once [0..*]
Definition A list of Transportation systems, such as surface roadways, inland waterways, airports, etc., so that each may be associated with a status.
Comments
Constraints Used in EDXL-SitRepSituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of SituationSummaryType
Source ICS 209
Requirements Sup-ported
Situation Summary-Information
4.7.1.1 ExternalAffairs Complex TypeThe ExternalAffairs element group provides information about concerns that are external to the ManagementReportingSummary context that nevertheless need to be taken into account by the responderorganizations and jurisdictions.
ElementType ExternalAffairsType
Type xs:complexType
Definition Tracks concerns that are external to the ManagementReportingSummary context
Usage OPTIONAL; may be used once and only once [0..1]
DefinitionThe EffectivePublicCommunication element is aimed at gauging whether or not the re-sponding agency is communicating well with the at-risk public as well as the public at large.
Comments
Constraints
Part of ExternalAffairsType
Source
Requirements Sup-ported
Incident-Response-Information
Element talkingPoints
Type xs:complexType
Usage OPTIONAL; may be used once and only once [0..1]
Definition TalkingPoints is the container element for individual Talking Points
DefinitionTalkingPoint is the individual item of information which the responding agency organiza-tion wishes to communicate to the public or coordinating agencies with regard to the inci-dent that the responding organizations are engaging.
Comments
Constraints
Part of ExternalAffairsType.talkingPoints
Source
Requirements Sup-ported
Incident-Response-Information
Element rumors
Type xs:complexType
Usage OPTIONAL; may be used once and only once [0..1]
Definition rumors is the container element for individual Rumor elements
Definitionrumor is the individual item of information which the responding agency organization wishes to communicate to the public or coordinating agencies with regard to the incident that the responding organizations are engaging.
4.7.1.2 DebrisManagement Complex TypeElements in the DebrisManagement ComplexType are used to track the details of debris management.in the incident being reported.
ElementType DebrisManagementType
Type xs:complexType
Definition Elements to track the details of debris management
Usage OPTIONAL; may be used once and only once [0..1]
Definition DaysToClearanceComplete stands for number of Days To Complete Clearance of Debris in the Incident being reported.
Comments
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DebrisManagementType
Source
Requirements Sup-ported
Situation Summary-Information
Element percentOfJurisdictionWithDebrisImpacts
Type ct:PercentageType
Usage OPTIONAL; may be used once and only once [0..1]
DefinitionPercentOfJurisdictionWithDebrisImpacts stands for Percent Of the Reporting Jurisdiction that has sustained the impact of Debris in the Incident being reported as a percentage of the total area of the Jurisdiction in question.
Comments
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DebrisManagementType
Source
Requirements Sup-ported
Situation Summary-Information
Element areasWithDebrisImpacts
Type ct:ValueListType
Usage OPTIONAL; may be used more than once [0..*]
Definition AreasWithDebrisImpacts stands for areas named in the ValueListType within the Jurisdic-tion in the Incident being reported which have Debris Impacts.
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DebrisManagementType
Source
Requirements Sup-ported
Situation Summary-Information
Element areasWhereWorkNotStarted
Type ct:ValueListType
Usage OPTIONAL; may be used more than once [0..*]
Definition AreasWhereWorkNotStarted stands for areas named in the ValueListType within the Ju-risdiction in the Incident being reported where work has not yet begun on Debris Removal.
Comments
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DebrisManagementType
Source
Requirements Sup-ported
Situation Summary-Information
Element debrisDisposedToDateCY
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition DebrisDisposedToDateCY stands for Total Debris disposed of in the Incident being re-ported in the unit of measure of Cubic Yards.
Comments
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Usage OPTIONAL; may be used once and only once [0..1]
Definition DebrisNotYetDisposedCY stands for Total Debris that has not yet been disposed of in the Incident being reported in the unit of measure of Cubic Yards.
Comments
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DebrisManagementType
Source
Requirements Sup-ported
Situation Summary-Information
Element debrisStorageSitesPercentFilled
Type ct:PercentageType
Usage OPTIONAL; may be used once and only once [0..1]
Definition DebrisStorageSitesPercentFilled stands for Percentage of Total space available in Debris Storage Sites which has been filled in the Incident being reported.
Comments
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DebrisManagementType
Source
Requirements Sup-ported
Situation Summary-Information
Element daysToDisposalComplete
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition DaysToDisposalComplete stands for number of days remaining to complete disposal of the debris in the incident being reported..
Comments
Constraints Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep
Definition Default value list: DamageCategoryDefaultValues
Comments
Constraints
Part of PropertyDamageType
Source
Requirements Sup-ported
4.7.2 DecisionSupportInformation Complex Type
Elements in the Incident DecisionSupportInformation element group provide general management-level status and descriptive information about resources, scope and status of the incident response, and time and cost estimates such as projected # Of People To Be Sheltered, Anticipated Incident Management Completion Date, and Emergency Response Issues / Operational Activities.Incident Decision Support information also utilizes the following supporting elements:
Used in ManagementReportingSummaryType.decisionSupportInformation
Requirements Sup-ported
Element projectedIncidentActivity
Type ct:ValueKeyStringPairType
Usage OPTIONAL; may be used once and only once [0..1]
Definition
An estimate when it is appropriate to do so of the projected incident activity, potential, movement, escalation, or spread and influencing factors during the next operational pe-riod. Direction/scope in which the incident is expected to spread, migrate, or expand dur-ing the next operational period, or other factors that may cause activity changes.
CommentsInclude an estimate of the acreage or area that will likely be affected. If known, provide the above information in 12-, 24-, 48- and 72-hour time frames, and any activity anticipated after 72-hours
Constraints Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DecisionSupportInformationType
Source ICS 209
Requirements Sup-ported
Incident-Decision-Support-Information
Element projectedNumberToBeSheltered
Type xs:unsignedInt
Usage OPTIONAL; may be used once and only once [0..1]
Definition The total number of people projected to require shelter due to the incident, to assist plan-ning and matching of resources.
Comments This is not a “CasualtyAndIllnessCategory”. This number is not included in any Casualty and Illness Summary totals
Constraints Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Usage OPTIONAL; may be used once and only once [0..1]
Definition The Date/Time at which incident containment or control is expected, or at which time the incident is expected to be closed or when significant incident support will be discontinued.
Comments
Constraints Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DecisionSupportInformationType
Source ICS 209
Requirements Sup-ported
Incident-Decision-Support-Information
Element projectedDemobilizationStartDate
Type EstimatedDateType
Usage OPTIONAL; may be used once and only once [0..1]
Definition The Date/Time at which major or significant demobilization is likely.
Comments
Constraints Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Usage OPTIONAL; may be used once and only once [0..1]
Definition An estimate of the total costs for the incident once all financial costs have been processedbased on current spending and projected incident activity levels.
Comments
Constraints
Always used with the CurrencyType common element (e.g. USD)
Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Part of DecisionSupportInformationType
Source ICS 209
Requirements Sup-ported
Incident-Decision-Support-Information
Element projectedFinalCosts
Type EstimatedCostsType
Usage OPTIONAL; may be used once and only once [0..1]
Definition An estimate of the total costs for the incident once all financial costs have been processedbased on current spending and projected incident activity levels.
Comments
Constraints
Always used with the CurrencyType common element (e.g. USD)
Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Brief overview of current and critical response activities, and initiatives for each Emer-gency Support Function (ESF) as applicable. Identify any new mission assignments. If not activated, so indicate. If deactivated, indicate deactivation date. Overview should be provided for each standard ESF as appropriate.
overall strategy, constraints, and current available information to:
1. Critical resource needs identified.2. The Incident Action Plan and management objectives and targets,3. Anticipated results.
Explain major problems and concerns such as operational challenges, incident manage-ment problems, and social, political, economic, or environmental concerns or impacts.
Comments
Constraints Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
“Jurisdiction” is a complex, reusable element used to identify and/or describe political Jurisdiction(s) (see glossary) affected by the incident.Also supported by the following elements:
LocationInformation: edxl-gsf [XML Structure]
ContactInformation: edxl-ciq [XML Structure]
Note: edxl-gsf & edxl-ciq contain a set of re-usable elements such as ContactDescription, ContactRole, ContactLocation, EDXLLocationType, and AdditionalContactInformation.
ElementType JurisdictionInformationType
Type xs:complexType
Definition
An XML structure containing four required elements (name, geographicSize, location, de-scription)
Provides information about any jurisdiction(s) that are associated with, impacted by or in charge of this incident.
Comments
Constraints
Valid Values /Examples
Sub-elements
• name [1..1]: xs:string
• geographicSize [1..1]: GeographicSizeType (1)
• location [1..1]: ct:EDXLLocationType
• description [1..1]: xs:string
Used inIncidentInformationType.jurisdictionInformation
The name of the jurisdiction (a pre-defined physical location or geo-political area, organi-zation or agency over which legal authority extends) affected by the incident, where the in-cident originated, or which holds certain authority within its own jurisdiction as well as au-thority and responsibility in regard to mutual aid agreements.
Part of the AffectedJurisdiction XML structure.
Comments
It is recognized that this definition mixes two types of concepts:
• Reference to an organization or agency that has “Authority” over something (such as an incident, or a set of identified resources). Jurisdiction in this sense may be general, such as “federal”, “city”, or “state”, or may be specific agency names such as “Warren County”, “US Coast Guard”, “Panama City”, and “NYPD”.
• Reference to a pre-defined physical location or geo-political area
Though a jurisdiction itself is not a person, role, or title, a jurisdiction has assigned to it one or more government personnel with legal authority for certain types of decision-making such as allocation of emergency resources and invocation of mutual aid agreements.
Constraints
Terms used on ICS-209: “Incident Location Information: Incident Jurisdiction”
Used in EDXL-SitRep SituationInformation and ManagementReportingSummary” Report Types.
Part of JurisdictionInformationType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information
Element geographicSize
Type GeographicSizeType
Usage REQUIRED [1..1]
Definition
Always paired with one “AffectedJurisdictionName”
May be used with the common element “Estimate” to indicate whether the size is estimated or known.
May be used with the common element “Remarks”
Comments
Constraints Used in EDXL-SitRep SituationInformation and ManagementReportingSummary” Report Types.
Refers to the physical location of the affected area within an “AffectedJurisdictionName”, applying reusable edxl-gsf components to express location information using a variety of options including geopolitical (e.g. addresses) and geospatial (e.g. lat/long).
Part of the AffectedJurisdiction XML structure.
Comments Always paired with one “AffectedJurisdictionName”
Constraints Used in EDXL-SitRep SituationInformation and ManagementReportingSummary” Report Types.
Part of JurisdictionInformationType
Source ICS 209
Requirements Sup-ported
Situation-Summary-Information
Element description
Type xs:string
Usage REQUIRED [1..1]
Definition
A textual descripton of the “AffectedJurisdictionName” which may provide further infor-mation about the incident effects on that Jurisdiction and/or description of the Affected-JurisdictionSize if precise information is not available.
Part of the AffectedJurisdiction XML structure.
Comments Always paired with one “AffectedJurisdictionName”
Constraints Used in EDXL-SitRep SituationInformation and ManagementReportingSummary” Report Types.
Definition Default enumerated values for reportVersion
CommentsThis 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”.
Constraints Enumeration
Valid Values /Examples
“Initial” - This is the first transmission of this kind of Report from the same source (“AuthorizedBy”) for this incident or event. The “Initial” Report MAY contain the “OriginatingMessageID”.
“Update” - A subsequent SitRep MessageReportType from the same source (“AuthorizedBy”) for the same incident or event.
“Final” - The last of this specific SitRep MessageReportType to be submitted from same source (“AuthorizedBy”) for the same incident or event. A SitRep may also have a ReportVersion of "Final" if they become part of a new Complex Incident (although this is rare)
Sub-elements
Used in SitRepType.reportVersion
Requirements Sup-ported
ElementType IncidentLifecycleDefaultValues
Type ct:ValueType
Definition Default enumerated values for incidentLifeCycle
“Immediate” - Responsive action SHOULD be taken immediately. “Expected” - Responsive action SHOULD be taken soon (within next hour). “Future” - Responsive action SHOULD be taken in the near future. “Past” - Responsive action is no longer required. “Unknown” - Urgency not known.
Sub-elements
Used in SitRepType.urgency
Requirements Sup-ported
ElementType ConfidenceDefaultValues
Type ct:ValueType
Definition Default enumerated values for reportConfidence
Comments
Constraints Enumeration
Valid Values /Examples
“HighlyConfident” – Topmost level of confidence. “SomewhatConfident” – Medium level of confidence. “Unsure” – Low level of confidence. “NoConfidence” – Lack of confidence – Can be used to support cancellation of previ-
ous report
Sub-elements
Used in SitRepType.reportConfidence
Requirements Sup-ported
ElementType SeverityDefaultValues
Type ct:ValueType
Definition Default enumerated values for severity
Comments Inherited from CAP 1.2
Constraints Enumeration
Valid Values /Examples
“Extreme” - Extraordinary threat to life or property. “Severe” - Significant threat to life or property. “Moderate” - Possible threat to life or property. “Minor” - Minimal threat to life or property. “Unknown” - Severity unknown
Used in FieldObservationType.immediateNeedsCategory
Requirements Sup-ported
ElementType IncidentKindDefaultValues
Type ct:ValueType
Definition Default enumerated values for incidentKind
Comments Inherited from EDXL-CAP CategoryType
Constraints Enumeration
Valid Values /Examples
“Geophysical” - Geophysical (inc. landslide) “Meteorological” - Meteorological (inc. flood) “GeneralEmergency” - General emergency “Safety” - Public safety “Security” - Law enforcement, military, homeland and local/private security “RescueAndRecovery” - Rescue and recovery “Rescue” - Rescue “FireSupressionAndRescue – Fire suppression and rescue “Fire” - Fire “MedicalAndPublicHealth” - Medical and public health “Health” - Health “PollutionAndEnvironmentalHazard” - Pollution and other environmental hazard “PublicAndPrivateTransportation” - Public and private transportation “Transport” - Transport “UtilityTelecommunicationOtherNonTranspotInfrastructure” - Utility, telecommunica-
tion, other non-transport infrastructure “CBRNE” - Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat
Definition Default enumerated values for incidentComplexity
Comments
Constraints Enumeration
Valid Values /Examples
“Complex” – Public / Professional preparedness is low, Coordination Complexity and involvement is high (local, regional, state and national)
“ModerateComplex” – Public / Professional preparedness is moderate-high, Coordi-nation Complexity and involvement is high (local, regional, state, possibly national).
“Moderate” – Public / Professional preparedness is high, Coordination Complexity and involvement is moderate (local, regional)
“Low” - Public / Professional preparedness is high, Coordination Complexity and in-volvement is low (local only)
Sub-elements
Used in IncidentInformationType.incidentComplexity
Requirements Sup-ported
ElementType DeploymentStatusDefaultValues
Type ct:ValueType
Definition Default enumerated values for deploymentStatus
“Fatalities” – Deceased “Hospitalized” – In-route or arrived at an Emergency Department or Hospital “WithInjuryOrIllness” – Physical or mental damage or sickness including those that
may be caused through a biological event such as an epidemic or an exposure to toxic or radiological substances.
“TrappedOrInNeedOfRescue” – In need of rescue due to incident or other conditions “Missing” – Cannot be located “Evacuated” – Accounted for and being evacuated from the scene “ShelteringInPlace” – Accounted for but sheltering in their original location at time of
the incident “InTemporaryShelters” – Accounted for and have been placed in a temporary shelter “InQuarantine” – Accounted for and under quarantine by authorities “ReceivedMassImmunizations” “RequireMassImmunizations”
Sub-elements
Used in CasualtyAndIllnessCountCategoryType.countCategory
Requirements Sup-ported
ElementType SignificantEventsDefaultValues
Type ct:ValueType
Definition Default enumerated values for significantEvents
“NoLikelyThreat” - No likely threat to life and safety. “PotentialFutureThreat” - Potential future threat to life and safety. “MassNotificationsInProgress” - Mass notifications in progress regarding emergency
situations, evacuations, shelter in place, or other public safety advisories relating to this incident. These may include use of threat and alert systems such as the Emer-gency Alert System or a “reverse 911” system.
“MassNotificationsCompleted” – “Casualty and Illness Summary” by Responder has been completed and submitted for this “ForTimePeriod”
“NoEvacuationsImminent” - Evacuations are not anticipated in the near future based on current information.
“PlanningForEvacuation” - Evacuation planning is underway in relation to this inci-dent.
“PlanningForShelterInPlace” - Planning is underway for shelter in place activities re-lated to this incident.
“EvacuationsInProgress” - There are active evacuations in progress relating to this in-cident.
“ShelterInPlaceInProgress” - There are active shelter- in-place actions in progress re-lating to this incident.
“RepopulationInProgress” - There is an active repopulation in progress relevant to this incident.
“MassImmunizationInProgress” - There is an active mass immunization in progress relevant to this incident.
“MassImmunizationComplete” - A mass immunization effort has been completed in specific relation to this incident.
“QuarantineInProgress” - There is an active quarantine in progress relative specifi-cally to this incident.
Sub-elements
Used in SituationSummaryType.lifeAndSafetyThreat
Requirements Sup-ported
ElementType InfrastructureAffectedDefaultValues
Type ct:ValueType
Definition Default values for infrastructureAffected
5 ConformanceThe EDXL-SitRep v1.0 specification has been written with the objective of making conformance to its re-quirements straightforward and unambiguous.
5.1 Conformance TargetsThe two following conformance targets are defined in order to support the specification of conformance to this standard:
• EDXL-SitRep Message; and• EDXL-SitRep Message Producer and Consumer.
An EDXL-SitRep Message is an XML 1.0 element whose syntax and semantics are specified in this stan-dard. An EDXL-SitRep Message Producer is a software entity that produces EDXL-SitRep Messages.
Note: All the existing requirements for the production of an incoming EDXL-SitRep message are, in fact, requirements on the type and content of the EDXL-SitRep message that a consumer MUST be capable ofconsuming in order to ingest and process an EDXL-SitRep message. Therefore, a conforming EDXL-SitRep Message Consumer will necessarily meet all the existing requirements for the production of EDXL-SitRep messages.
5.2 Conformance Summaries for EDXL-SitRep Messages and Producers
In summary, an EDXL-SitRep Message is one of the five (5) report type elements specified in sections 3.4.2 to 3.4.6.
Requirements for an EDXL-SitRep Message Producer are given in Section 5.4, and summarized here. An EDXL-SitRep Message Producer is a software entity that produces conforming EDXL-SitRep Messages whenever an EDXL-SitRep Message is expected.
5.3 Conformance as an EDXL-SitRep Message
5.3.1 EDXL-SitRep MessageAn XML 1.0 element is a conforming EDXL-SitRep Message if and only if:
a) it meets the general requirements specified in Section 3.3;b) if its namespace name is "urn:oasis:names:tc:emergency:EDXL:SitRep:1.0:msg", then its local
name is one of the five (5) report type names specified in sections 3.5 to 3.9 (also listed in Table 1), and the element is valid according to the schema located at http://docs.oasis-open.org/emergency/EDXL-SitRep/EDXL-SitRep.xsd, where validation is per-formed against the element declaration with the same local name;
c) if its namespace name is "urn:oasis:names:tc:emergency:EDXL:SitRep:1.0:msg", then its content (which includes the content of each of its descendants) meets all the additional mandatory re-quirements provided in the specific subsection of Section 3 (sections 3.5 to 3.9) corresponding to the element’s name, with the exception of the Message Flow; such requirements include:◦ the content of the Element Reference Model;◦ each of the Message Rules; and◦ the normative parts (element name, usage, and constraints) of any Data Dictionary entries (in
Section 4.) corresponding to the elements that actually occur in the content of the element;
5.4 Conformance as an EDXL-SitRep Message ProducerA software entity is a conforming EDXL-SitRep Message Producer if and only if it is constructed in such a way that any XML 1.0 element produced by it and present in a place in which a conforming EDXL-SitRep message is expected (based on contextual information) is indeed a conforming EDXL-SitRep message according to this standard.
Note: The condition above can be satisfied in many different ways. Here are some examples of possible scenarios:
• a standard distribution protocol (say, EDXL-DE) transfers EDXL-SitRep messages; a branch of a local responder agency involved in responding to a local incident has sent an EDXL-SitRep Situa-tionInformation Report Type message to an the Incident Command Divisional Commander which claims to be a conforming EDXL-SitRep Message Producer and Consumer, and has received an EDXL-DE message of DistributionType “Ack” including the MessageID of the EDXL-SitRep Situa-tionInformation Report Type message sent earlier, which is therefore expected to communicate that the EDXL-SitRep SituationInformation Report Type message sent earlier has been received and ingested.
• a local test environment has been set up, and the application under test (which claims to be a conforming EDXL-SitRep Message Producer) has the ability to produce an EDXL-SitRep mes-sage and write it to a file in a directory in response to a request coming from the testing tool; the testing tool has sent many requests to the application under test and is now verifying all the files present in the directory, which is expected to contain only conforming EDXL-SitRep Messages.
Appendix B EDXL-SituationReporting XML SchemaThe EDXL-SituationReporting XML Schema is provided here for the sake of convenience and as a separate file that can be downloaded at
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csd01/schemas-and-examples/EDXLSitRep.xsd. Please note that all schemas needed for implementation of this specification can also be found at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csd01/schemas-and-examples/
<?xml version="1.0" encoding="utf-8"?> <!-- Emergency Data Exchange Language Situation Reporting (EDXL-SitRep) Version 1.0 Working Draft WD22 26 July 2015 Copyright (c) OASIS Open 2015. All Rights Reserved. --> <!-- edited with XMLSpy v2012 sp1 (x64) (http://www.altova.com) by Donald P. McGarry et al. (The Mitre Corporation) --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:edxl-gsf="urn:oasis:names:tc:emergency:edxl:gsf:1.0" xmlns:ct="urn:oasis:names:tc:emergency:edxl:ct:1.0" xmlns="urn:oasis:names:tc:emergency:EDXL:SitRep:1.0" xmlns:ext="urn:oasis:names:tc:emergency:edxl:extension:1.0" targetNamespace="urn:oasis:names:tc:emergency:EDXL:SitRep:1.0" elementFormDefault="qualified" attributeFormDefault="qualified"> <xs:import namespace="urn:oasis:names:tc:emergency:edxl:ct:1.0" schemaLocation="./edxl-ct-v1.0-wd05.xsd"/> <xs:import namespace="urn:oasis:names:tc:emergency:edxl:gsf:1.0" schemaLocation="./edxl-gsf.v1.0.xsd"/> <xs:import namespace="urn:oasis:names:tc:emergency:edxl:extension:1.0" schemaLocation="./edxl-ext-v1.0.xsd"/> <xs:complexType name="IReport" abstract="true"> <xs:sequence> <xs:element name="extension" type="ext:ExtensionType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!--Complex Types in Document Order--> <xs:complexType name="DisasterInformationType"> <xs:sequence> <xs:element name="disasterName" type="xs:string"/> <xs:element name="disasterDeclarationAuthority" type="xs:string"/> <xs:element name="disasterDeclarationDateTime" type="ct:EDXLDateTimeType"/> </xs:sequence> </xs:complexType> <xs:complexType name="IncidentStagingType"> <xs:sequence> <xs:element name="incidentStagingArea" type="xs:string"/> <xs:element name="incidentStagingAreaLocation" type="ct:EDXLLocationType"/> </xs:sequence> </xs:complexType> <xs:complexType name="ResourceTotalType"> <xs:sequence> <xs:element name="branchDivisionGroup" type="ct:EDXLStringType"/> <xs:element name="resource" type="ResourceCountType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="ResourceStatusType"> <xs:sequence> <xs:element name="inventoryRefreshDateTime" type="ct:EDXLDateTimeType"/> <xs:element name="deploymentStatus" type="DeploymentStatusDefaultValues" minOccurs="0"/> <xs:element name="availability" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:complexType name="ResourceCountType"> <xs:sequence>
Appendix C.1 Selecting values from listsThe ValueList and ValueKey types are part of the EDXL Common Types collection. They allow standards adopters to use topic specific lists of values for elements such as raceEthnicity, fluenSpokenLanguages, specialTransportationNeeds, etc.. Both types have identical structure, but ValueList allows for selection of multiple values [1..*] in the list, whereas ValueKey allows for selection of only one [1..1] value in the list.
When using a ValueList / ValueKey structure the user can specify a user-defined list by URI (either using the “urn:...” format or the more familiar “http://...” format) and then include user-defined values from that list. This structure has several advantages: (a) it provides flexibility for local communities to use community-defined terms and vocabulary; (b) it allows for the external maintenance of local or standardized lists; and (c) it avoids the problems inherent in attempting to constantly update hard-coded enumerations in a specification.
An existing vetted list should be referenced for defaults, but users could also reference their own value list.
In the Data Dictionary we describe examples of elements of type ct:ValueListType by listing value assignments to valueListURI and value_1, …, value_n.
So for instance an example for “specialMedicalNeeds” is described by– valueListURI = urn:myagency:gov:ahrq:specialMedicalNeeds and– value_1 = Ventilator– value_2 = Oxygen
This example contains two special needs, one whose value is “Ventilator” and one whose value is “Oxygen”. These are notional needs created for this example. The needs are identified as values from a list whose unique Uniform Reference Identifier (URI) is “urn:myagency:gov:ahrq:specialMedicalNeeds”.
A note about ValueList: the multiplicity of ValueList can be a source for confusion. Typically, 1 is the maximum number of occurrences of ValueList. This means that at most one such list may occur for a given element; this does not preclude the user from selecting multiple entries from that list (maxOccurs = “unbounded”).
Following the approach in ValueList, we'd point ValueListURI to some other list to make a different selection of eye colors available.
Appendix C.2 EDXL ExtensionsThe challenge when developing standardized formats is to balance the need to define specific elements of emergency information that we can all agree upon and yet provide flexibility for local communities to include their particular information using their familiar vocabulary. EDXL addresses this concern by providing the common defined terms in the formal standards for the former, and by providing extension mechanisms for the latter.
Typical needs are:
1. Community augmentation: community adds new information that is associated with the EDXL standard. Examples: adding HL7 translation information to the TEP.
2. List augmentation: community adds new values (enumerations) to the default set of values in the standard. Example: adding FlightRisk value to the TEP contingencyMedicalSpecialityCode list.
3. List replacement:: community replaces the default set of values in the standard in its entirety. Example: defining TriageStatus with number codes instead of colors.
4. List redefinition: community reassigns the meaning of the default set of values in the standard in its entirety. Example: redefining the Black TriageCode to mean actively dying but not yet deceased.
EDXL combines the CommunityExtension mechanism with the ValueList and ValueKey types to deal with these needs. CommunityExtension addresses need 1.; ValueList / ValueKey address need 3. ; and combined they address needs 2. and 4.
For more details about EDXL Extensions and usage guidance, refer to the white paper [EDXL Extensions] referenced in section 1.6 above.
A “CommunityExtension”, or simply “Extension”, is a term used to describe supplemental message information that a community wants to add to the otherwise standard message information normally contained within an EDXL standard message. It is defined by the ExtensionType which consists of a [1..*] set of name/value pairs.
The schema for ExtensionType is defined as
<xs:complexType name="ExtensionType"><!-- Base type to allow communities to extend/augment an EDXL data standard --><xs:sequence>
<xs:element name="community" type="xs:anyURI"><!-- Unique community identifier -->
Note that this mechanism should be used only for required elements – if an element is optional, it could be completely replaced by any community extension, with its own name and structure.
Note also that for each example we assume that the schema contains the following element to allow for adding extensions:
Appendix C.2.2 List augmentationIf the list is defined as a ValueList or a ValueKey, then use the corresponding mechanisms described above to point to revised lists. If the list is defined as an enumeration, then the augmentation can be achieved with the Extension mechanism.
The following example illustrates the use of ExtensionType to add community specific enumeration(s).
Example: adding “ReleasedForRehab” and “PostRehabRecidivismt” o PatientCurrentDispositionDefaultValues enumeration in TEP
Appendix C.2.3 List replacementIf the list is defined as a ValueList or a ValueKey, then use the corresponding mechanisms described above to point to a replacement list. If the list is defined as an enumeration, then the replacement can be achieved with the Extension mechanism.
Example: the default triage codes are {“Red", "Yellow", "Green, "Blue", "Black" and "ExtensionValue"}. To allow for the use of “Purple” from a different list of values, the TEP message would look like:
Appendix C.2.4 List redefinitionIf the list is defined as a ValueList or a ValueKey, then use the corresponding mechanisms described above to point to list redefinitions. If the list is defined as an enumeration, then the redefinition can be achieved with the Extension mechanism. Note that list redefinition may pose significant risk to
interoperability and therefore, whether the list is completely redefined or only partially, best practices suggest that the extension mechanism must be used, to signal that risk.
Example: if one or more triage values are the same but have different meaning, then we use a redefined list with Extension:
Example code for each of the Situation Reports contained in this specification are available at: http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csd01/schemas-and-examples/
These examples show all required and optional elements for each of the reports.
Appendix D.1 ICS209 Web Form ExampleThe following example shows how a typical Incident Command System (ICS) form ICS209 using EDXL-SitRep-v1.0 could be filled out. The six images that follow show vertically sequential web browser screenshots that use the code for the XSLT Stylesheet and the example code for this example that are also available at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csd01/schemas-and-examples/
