All text is normative unless otherwise labeled

1.1 Purpose

The ongoing goal of the Emergency Data eXchange Language (EDXL) project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved.

The current roster of EDXL Standards includes:

§ The Common Alerting Protocol v1.2 specification (EDXL-CAP)

§ The Distribution Elementspecification 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 History

Through a practitioner-driven approach, the Command, Control and Interoperability Division (CID) within the U.S. Department of Homeland Security's Science and Technology Directorate creates and deploys information resources to enable seamless and secure interactions among state, local, tribal, international, private entities, homeland security stakeholders and other federal entities. CID creates and deploys Information resources such as standards, frameworks, tools, and technologies.

CID is organized into five program areas: Basic/Futures Research; Cyber Security; Knowledge Management Tools; Office for Interoperability and Compatibility (OIC); and Reconnaissance, Surveillance, and Investigative Technologies.

Following voice interoperability programs such as SAFECOM, the OIC’s interoperable messaging standards program was initiated as one of the President’s e-Gov initiatives in 2001. The OIC mission is to serve as the standards program within the Federal Government to facilitate local, tribal, state, and federal public safety and emergency response agencies to improve emergency / disaster response through effective and efficient interoperable data sharing. OIC sponsors the process to facilitate practitioner requirements for the development of EDXL standards.

EDXL will accomplish this mission through the standardization of specific messages (XML messaging interfaces) which facilitate coordination and emergency communication between disparate software applications and systems - particularly when more than one profession or jurisdiction is involved.

The EDXL program is an open, public practitioner-driven process driven solely by cross-profession emergency practitioners through an OIC-sponsored Practitioner Steering Group (PSG) and Standards Working Group (SWG). The EDXL program is also a public-private partnership working with the EIC (Emergency Interoperability Consortium), Vendor communities, and OASIS (Organization for the Advancement of Structured Information Standards), which develops and publishes the open, public EDXL standards free of charge.

The OIC-sponsored Practitioner Steering Group (PSG) governance was formalized following publication of the EDXL Distribution Element. It plays a key role in the direction, prioritization, definition, and execution of the DHS-OIC program. The group is comprised of representatives of major emergency response associations and organizations, setting priorities and providing recommendations regarding messaging standards development as well as the other facets of the OIC-EDXL program.

The PSG identified the EDXL Situation Reporting (EDXL-SitRep) Specification effort as the top priority standard by this group following the development of EDXL-DE, EDXL-HAVE and EDXL-RM. Utilizing standard process and governance, the requirements and specification effort was initiated by this group in partnership with industry members of the Emergency Interoperability Consortium (EIC) and the Standards Working Group (SWG). The EDXL-SitRep draft specification was developed based on explicitly defined requirements which were submitted to the OASIS Emergency Management Technical Committee (EM-TC) to begin work on this international EDXL-SitRep standard.

Tthe EDXL Situation Reporting standard defines five (5) separate and specific report types to support incident command decision-making across the emergency incident life-cycle. This includes preparedness, pre-staging of resources, initial, ongoing response, recovery and demobilization / release of resources and after-action analysis to identify needed improvements in ongoing preparedness.

1.3 Structure of the EDXL Situation Reporting Specification

The EDXL Situation Reporting standard document structure is defined using successively more detailed or constrained artifacts in the form of textual descriptions, diagrams, figures, tables and Appendices. The EDXL-SitRep XML Schema is provided separately.The overall structure of the EDXL Situation Report is first represented in an Element Reference Model (ERM). The ERM is the foundation from which individual constraint schemas (individual situation report types) are defined.

The structure of the EDXL Situation Reporting standard is defined in the following sections:

· Section 3.1, The Element Reference Model (ERM), shows the abstract structural relationships of the main components of the EDXL-SitRep.

· Section 3.2, Distribution of EDXL Situation Reporting, describes practitioner requirements which are met through the EDXL-Distribution Element (DE)

· Sections 3.3.2 through 3.3.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 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.

The EDXLSitRepRoot element of the EDXL-SitRep message, containing elements used throughout each individual situation report such as IReport, MessageID, PreparedBy, and IncidentID.
A SituationInformation report type identifies and describes the incident with message elements such as IncidentName, IncidentLocation and IncidentType.
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.
A CasualtyAndIllnessSummary report type provides counts by responder and non-responders for various categories such as fatalities, missing and hospitalized over specified time periods. These data items may be collected as needed and combined in the manner required for specific reports or for decision making purposes.
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.
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.

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 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

The term “Conditional” as used in this specification is to be interpreted that a message element MUST be used, according to specified rules, within a particular report message type (elements MUST be one of “Required,” “Optional” or “Conditional”).

1.5 Normative References

[EDXL-SitRep-

Rqmts] EDXLSituation Reporting Requirements 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, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txt, November 1996.

[RFC3066] H. Alvestrand, Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc3066.txt, IETF RFC 3066, January 2001.

[WGS 84] National Geospatial Intelligence Agency, Department of Defense World Geodetic System 1984, http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf, NGA Technical Report TR8350.2, January 2000.

[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), http://www.w3.org/TR/REC-xml/, W3C REC-XML-20040204, (Fifth Edition) 26 November 2008.

[namespaces] T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C REC-xml-names-19990114, (Third Edition) W3C Recommendation 8 December 2009

[dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#dateTime, W3C REC-xmlschema-2, October 2004.

[EDXL-DE] Emergency Data Exchange Language (EDXL) Distribution Element v1.0. 1 May 2006. OASIS Standard 01. http://docs.oasis-open.org/emergency/edxlde/v1.0/EDXL-DE_Spec_v1.0.pdf

[EDXL-HAVE] Emergency Data Exchange Language (EDXL) Hospital AVailablity Exchange.. OASIS Standard 01 http://docs.oasis-open.org/emergency/edxlhave/v1.0/emergency_edxl_have-1.0.html, 1 November 2008

[EDXL-RM] Emergency Data Exchange Language (EDXL) Resource Messaging. OASIS Standard. V1.0. http://docs.oasis-open.org/emergency/edxl-rm/v1.0/errata/EDXL-RM-v1.0-OS-errata-os.html, 1 November 2008

[EDXL-CT] Emergency Data Exchange Language Common Types 1 Committee Specification Draft 01 http://docs.oasis-open.org/emergency/edxl-ct/v1.0/edxl-ct-v1.0.pdf, 12 December 2011

[EDXL-CIQ] Emergency Data Exchange Language Customer Information Quality OASIS Committee Specification Draft 01 http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/edxl-ciq-v1.0.pdf, 14 March 2012

[EDXL-GSF] Emergency Data Exchange Language GML Simple Features Profile OASIS Committee Specification Draft 01 http://docs.oasis-open.org/emergency/edxl-gsf/v1.0/edxl-gsf-v1.0.pdf, 7 December 2011

[OGC CRS] Open Geospatial Consortium, Topic 2 - Spatial Referencing by Coordinates (Topic 2) (CRS Abstract Specification), https://portal.opengeospatial.org/files/?artifact_id=6716, Version 3, 2004.

1.6 Non-Normative References

[EDXL GFR] EDXL General Functional Requirements, http://www.oasis-open.org/committees/download.php/10031/EDXL%20General%20Functional%20Requirements.doc, November 2004

[EDXL-DE IG] EDXL Distribution Element Implementer's Guide, http://www.oasis-open.org/committees/download.php/14120/EDXL_Implementer%27sGuide.doc, August 2005

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

http://www.oasis-open.org/committees/download.php/32278/EDXL-SitRep-Rqmts-MsgSpec020209.doc

2.2 Example Usage Scenarios

Note: The following examples of usage scenarios were used as a basis for development of the practitioner requirements and messaging specification document which was submitted to OASIS. These scenarios are non-normative and not intended to be exhaustive or to reflect actual practices.

2.2.1 Train Derailment Example

This scenario follows the detection of a train derailment either by a GPS system or by a citizen report via 911/PSAP. An early use case, this specific case illustrated a number of areas where a clarification of the system needs to be made.

Full use case available: http://www.oasis-open.org/committees/download.php/32043/EDXL_use_case_Train_Derailv1.5final.doc

This scenario includes subsequent developments in a traffic accident and biohazard incident.

2.2.2 Levee Break and Evacuation with Law Enforcement Focus

The National Weather Service is reporting that there is no let-up in sight to the rain storm that has been drenching the area for the last 36 hours. An unprecedented amount of rain has fallen. A levee next to a local town is threatening to break.

Estimates of engineers indicate that the levee will only hold for another 2 hours. This is the time frame in which the initial response must take place. Emergency Management has notified local law enforcement: that the 2,000 residents at risk must be evacuated immediately. 200 are elderly, of which 50 are non-ambulatory.

Rising water levels also threaten to cause two major rivers, one flowing through a major neighboring town to the west, to overflow their banks and cause massive flooding across the region. These floods will impact areas of the original town not affected by the impending levee break.

If these rivers do overflow their banks, then an additional and much larger number of people will need to be warned and evacuated.

Full use case available: http://www.oasis-open.org/committees/download.php/32042/EDXL_use_case_LeveeBreakEvac_v1.1final.doc

2.2.3 EMS Call

This scenario takes place in Bayport on a coastal island across a bridge from Fisherville on the mainland. The nearest large city is Central City which is 40 miles away and has two hospitals. The first, Faith Hospital, is a regional cardiac catheterization and care center. Central City Hospital is a level 1 trauma center and operates a medevac helicopter service called Med Flight-1. Fisherville has a small community hospital with a physician-staffed ER. Fisherville Hospital runs a health clinic in Bayport, staffed by a physician assistant. The Bayport EMS (BEMS) staff supports the physician assistant, as well as Central City and Faith Hospital physicians who have patients in Bayport, by working in the clinic

Full use case available: http://www.oasis-open.org/committees/download.php/32041/EDXL_use_case_EMS_Callv1.4final.doc

2.2.4 Road Rescue -- Highway Incident Scenario & Use Case

This scenario timeline was pieced together using actual documents supporting the “ROAD RESCUE 06 Exercise Plan”, a joint, full scale mass casualty exercise involving Baltimore County, the private sector and the State of Maryland on March 20, 2006.

Full use case available: http://www.oasis-open.org/committees/download.php/32040/RoadRescue06ScenarioV1.3final.doc

2.2.5 Pandemic Influenza

This scenario models an H5N1 Influenza Pandemic outbreak first detected in South China which then spreads out to global involvement. This use case details the communications using EDXL, during the various stages or phases of response.

Full use case available: http://www.oasis-open.org/committees/download.php/32039/Pandemic_Influenza_ScenarioV1.7final.doc

3 EDXL Situation Reporting Model (Normative unless otherwise 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 shall always take precedence and the other artifact(s) must be changed to match the XML schema.
Note: Please report any such errors to OASIS.

3.1 Element Reference Model (Non-normative)

Figure 2 below shows the EDXL–SitRep Element Reference Model (ERM). The purpose of the ERM is to define the SitRep structure and the relationships between the main entities and their elements. Using the Unified Modeling Language as a means to illustrate the relationships, the ERM is not strictly normative. It is important that the ERM is not used as an implementation model. The exact semantics and structure are captured in the subsequent sections in the specific predefined EDXL Situation Report Message Types.

The ERM is organized into 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 provided separately and included in Appendix Appendix B uses the Abstract Type <IReport> element as the basis for the <Report> element in the EDXLSitRepRoot. The five report types shown in Figure 1 below are the types which may be declared using the <Report> element thus:

The code above declares the Report type based on <IReport> from EDXL-SitRep XML Schema shown below:

<xs:complexType name="IReport" abstract="true"/>

This is more completely explained in the Data Dictionary Section

Figure 1: <Report> and <IReport>Elements

Figure 2: EDXL–SitRep Element Reference Model (ERM)

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.6.

3.2 Distribution of EDXL-SitRep

The primary purpose of the Emergency Data Exchange Language Situation Reporting (EDXL-SitRep) Specification is to provide a set of standard formats for XML emergency messages containing information pertaining to the situation with which the message senders and recipients are involved. These EDXL-SitRep Messages are specifically designed as payloads of the EDXL-DE. Together EDXL-DE and EDXL-SitRep are intended to expedite activities associated with reporting on various situation and response activities. As set forth in Design Principles, routing and distribution information is found only in the EDXL-DE and not in the EDXL-SitRep.

While the EDXL-SitRep is designed to be an EDXL-DE payload, other routing mechanisms may be used to distribute EDXL-SitRep content if the message metadata is provided in the same form or if the sender specifies specific recipients of the payload.

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 information systems using XML. The EDXL-DE may be used over any data transmission system, including, but not limited to, the SOAP HTTP binding.

The primary purpose of the Distribution Element is to facilitate the routing of emergency messages to recipients. The Distribution Element may be thought of as a container. It provides the information to route "payload" message sets by including key routing information such as distribution type, geography, incident, and sender/recipient IDs. Messages may be distributed to specific recipients, to recipients in a geographic area, or based on codes such as agency type (police, fire, etc.).

The following subsections describe practitioner requirements which are met through the EDXL-Distribution Element (DE)

3.2.1.1 Identifying SitRep MessageType

The Requirement for identifying the “Message Type” of the EDXL-SitRep is handled by the <distributionType> element of EDXL-DE v1.0. This is distinct from the “Report Type” of an EDXL-SitRep message. It is expected that most EDXL-SitRep messages will be of <distributionType> “Report” shown below.

The <distributionType> element defines the function of the message and this functional name for the EDXL-SitRep “Message Type” takes the form of an XML enumeration where the value must be one of:

§ Report - New information regarding an incident or activity.

§ Update - Updated information superseding a previous message.

§ Cancel - A cancellation or revocation of a previous message.

§ Request - A request for resources, information or action.

§ Response - A response to a previous request.

§ Ack - Acknowledgment of receipt of an earlier message.

§ Error - Rejection of an earlier message (for technical reasons).

It is important to note, as will be detailed later, that identifying a text message as a “Request” for a Situation Report is handled by the EDXL <distributionType> element.

3.2.1.2 Indentifying Message Sender

The Requirement for identifying the “Message Sender” of the EDXL-SitRep is handled by one or two elements of EDXL-DE v1.0.The EDXL-DE v1.0 <senderID> or an element with the identical definition and properties MUST be present in the EDXL-DE or other routing mechanism used to distribute an EDXL-SitRep message. The <senderRole> or an element with the identical definition and properties MAY be present.

<senderRole> is expressed in an XML ValueList and Value.

§ The list and associated value(s) is in the form:

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

The EDXL-DE v1.0 <dateTimeSent> element is used to established the date and time the EDXL-DE package contained 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 Type

The message payload of an EDXL-DE package is a <contentObject> identified as <xmlContent> with a <contentDescription> of the EDXL-SitRep Report Type, i.e. FieldObservation, SituationInformation, ResponseResourcesTotals, CasualtyAndIllnessSummary or ManagementReportingSummary.

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 BinaryObject

The Requirement to carry a SitRep “map” or “sketch” as an object or image is handled by the the EDXL-DE v1.0 <nonXMLContent> object. The map or sketch may, for example provide information about the total incident area or total area of operations.

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. This should be provided in the form of a graphic image carried by the EDXL-DE message header as separate content object.

3.2.1.8 Signature

A digital version of a signature may optionally be included to provide the authority that authenticates a particular Situation Report. A digital signature must be provided in the form of a graphic image carried by the EDXL-DE message header as separate content object.

3.2.1.9 Sensitivity and Releasability

The Requirement for identifying the “Sensitivity” or “Releasability” of an EDXL-SitRep is handled through the EDXL-DE v1.0 elements <Confidentiality> and <combinedConfidentiality>.

EDXL-DE has a top-level element <combinedConfidentiality> that indicates the confidentiality of the combined "Content Object" sub-elements. Generally the combined confidentiality is the most restrictive of the confidentiality elements in the "Content Object" element, but it can be more restrictive than any of the individual "Confidentiality" elements.

The <combindedConfidentiality> element MUST be present if a "Confidentiality" element is present in any of the “Content Object” elements.

"Confidentiality" elements are specified in ValueList structures and are used to meet the EDXL-SitRep requirements for "Sensitivity Text" approximately equivalent to a set of values like "Top Secret," "Sensitive, and Classified" and "Sensitive, but Unclassified."

"Confidentiality" elements are also used to meet the EDXL-SitRep requirements for "Releasability Level" which might also be approximately equivalent to a set of values above, but which might also be different, even within a single jurisdiction. So each jurisdiction should establish its own published ValueLists and policies governing these issues.

3.3 Situation Report Root and Report Types

As further described below, the EDXLSitRepRoot element is the top level element of the EDXL-SitRep message, containing elements used throughout each individual situation report. This section describes the primary components of EDXL-SitReps 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 a distribution mechanism with the distribution type values of Report, Update, Cancel, Request, Response, Ack and Error, as defined in EDXL-DE.

For example, the acknowledgement of a SitRep message is handled by the distribution mechanism. When a message recipient receives a SitRep message, it uses the EDXL-DE DistributionType value of “Ack” as an acknowledgement. An acknowledgement is intended to inform the sender that the SitRep message has been received.

EDXL-SitRep communication is characterized by two classes of primary actors An “Incident Command” is an actor that needs or requires a situation report to undertake response decision(s) during an incident. An “Incident Command System” is an owner, or distributor, or manager of situation reports that can meet the needs of Incident Command. These actors need not belong to the same jurisdiction or organization.

EDXL-SitRep provides five (5) situation report messages defined in this standard, which are summarized in Table 1 below.

Table 1: Situation Report Message Type Summary-- informative only. It shows how situation reports might flow in incident command

Message Type	Description	Message Sender
FieldObservation	Basic report that describes an observation that is directly observed by the reporter (an emergency professional).	On-Scene Incident Command / Planning Section / Situation Unit
SituationInformation	Message used to provide information on responding resources and resource needs to manage and coordinate resource decisions.	On-Scene Incident Command / Planning Section / Situation Unit
ResponseResourcesTotals	Message used to provide information on responding resources and resource needs to manage and coordinate resources.	On-Scene Incident Command / Logistics Section
CasualtyAndIllnessSummary	Message used to summarize information pertaining to the number and status of categorized casualites and victims of infectious agents associated with the incident.	Incident Command System/ Logistics Section / Services Unit / Medical Services
ManagementReportingSummary	Message used to summarize information and data relevant to ongoing management of incident response, typically used within the Incident Command Chain or across such chains between jurisdictions	Incident Command System / PIO / Logistics Section / Communications

Table 2 (below) summarizes all the Message Types and their element contents, Including the Situation Report Root elements that can be used in any Message Type. The specific details on each of the Message Types are outlined in the following sections.

Table 2: Message Element Lists and Constraints (Key: R = Required, C = Conditional, O = Optional)

Table 2.1: Situation Report Root – applies to all message types

Message Element	[ ]	Message Element	[ ]	Message Element	[ ]
MessageID	1..1	PreparedBy	1..1	AuthorizedBy	1..1
ReportPurpose	1..1	ReportNumber	1..1	ReportVersion	1..1
ForTimePeriod	1..1	ReportTitle	0..1	IncidentID	1..*
IncidentLifecyclePhase	0..*	OriginatingMessageID	0..1	PrecedingMessageID	0..*
Urgency	0..1	ReportConfidence	1..1	Severity	1..1
ReportingLocation	0..1	ActionPlan	0..1	NextContact	0..1
Report	1..1

Table 2.2: FieldObservation

Message Element	[ ]	Message Element	[ ]	Message Element	[ ]
ObservationLocation	1..1	ImmediateNeeds	1..1	ImmediateNeedsCategory	0..*
ObservationText	1..1

Table 2.3: SituationInformation

Message Element	[ ]	Message Element	[ ]	Message Element	[ ]
IncidentName	1..*	IncidentType	0..*	IncidentComplexity	0..1
IncidentStartDateTime	0..1	IncidentGeographicSize	0..1	IncidentLocation	1..1
DisasterInformation	0..*	JurisdictionInformation	1..*	IncidentStaging	1..*

Table 2.4: ResponseResourcesTotals

Message Element	[ ]	Message Element	[ ]	Message Element
ResourceTotal	0..*	OrganizationAndAssignments	0..*
ResourceTotal
BranchDivisionGroup	1..1	Resource	1..*
ResourceTotal.Resource
AgencyOrganization	1..1	ResourceName	1..1	ResourceTypeCategoryKind	0..1
ResourceDetail	0..1
ResourceTotal.Resource.ResourceDetail
ResourcePersonnelCount	0..1	UnassignedResourcePersonnel	0..1	ResourceRequiredCount	1..1
ResourceCommittedCount	1..1	ResourceOnHandCount	1..1	ResourceNeededCount	1..1
ResourceRequestedCount	1..1	DateTimeOrdered	0..1	RequestedArrival	0..1
EstimatedArrival	0..1	ReportToLocation	0..1	OverheadPosition	0..*
WorkAssignment	0..1	SpecialInstructions	0..1	SpecialEquipmentAndSupplies	0..*
AdditionalAssistingOrganizations	0..1
OrganizationAndAssignments
CommandStructure	0..1	PositionTitle	0..1	PersonName	0..1
Branch	0..1	ReportsToPositionTitle	0..1	ReportsToPersonName	0..1
ReportsToAgency	0..*	ReportsToBranch	0..1

Table 2.5: CasualtyAndIllnessSummary

Message Element	[ ]		Message Element	[ ]	Message Element	[ ]
SummaryCount	0..*		NotifiableDiseaseNumbers	0..*
SummaryCount
CasualtyAndIllnessCountCategory		1..1	ResponderSummaryCount	0..1	NonResponderSummaryCount	0..1
ResponderSummaryCountToDate		0..1	NonResponderSummaryCount-ToDate	0..1	HaveReceivedMassImmunizationsCount	0..1
RequireMassImmunizationsCount		0..1	ShelterCountEstimate	0..1
NotifiableDiseaseNumbers
DiseaseSuspected		1..1	ProbableCause	1..1	CountOfSuspectedCases	1..1
CountOfConfirmedCases		1..1

Table 2.6: ManagementReportingSummary

Message Element	[ ]	Message Element	[ ]	Message Element	[ ]
SituationSummary	0..1	DecisionSupportInformation	0..1	JurisdictionInformation	0..*
SituationSummary
IncidentCause	1..1	SignificantEvents	0..*	DamageAssessmentInformation	0..*
PrimaryHazards	0..1	HazMatIncidentReport	0..1	ExtentOfContamination	0..1
GeneralPopulationStatus	0..1	HumanLifeAndSafetyThreat	0..1	LifeAndSafetyThreat	0..1
IncidentThreatSummaryAndRisk	0..*	FollowOnIndication	0..1	InfrastructureAffected	0..1
PropertyDamage	0..*	PercentContained	0..1	RequestsForAdditionalSupport	0..1
TerrorismNexus	0..1	WeatherEffects	0..1	WMDEffects	0..1
TransportationSystems	0..*
DecisionSupportInformation
ProjectedIncidentActivity	0..1	ProjectedNumberToBeSheltered	0..1	CriticalResourceNeeds	0..*
ProjectedFinalIncidentSize	0..1	AnticipatedCompletionDate	0..1	ProjectedDemobilizationStartDate	0..1
EstimatedCostsToDate	0..1	ProjectedFinalCosts	0..1	EmergencyResponseIssues	0..1
StrategicDiscussion	0..1	PlannedActions	0..1
JurisdictionInformation
Name	1..1	GeographicSize	1..1	Location	1..1
Description	1..1

3.3.1 E DXLSitRepRoot Elements

EDXLSitRepRoot elements are the collection of elements shown in the Element Reference Model below. The SitRepRoot is at the top of SitRep structure. These elements are common to all EDXL-SitRep Report types, and each of these elements can appear in any report.In contrast to the Supporting Element Types which are common, re-usable elements applicable across the Emergency Data Exchange Language standards, SitRepRoot elements are specific to EDXL-Situation Reporting.

Figure 3: EDXLSitRepRoot Elements
It is of particular significance to note the relationship of the <FromDateTime> and <ToDateTime> elements to their parent element <ForTimePeriod>. In this case, while both child elements are REQUIRED whenever the parent element is present, the parent element itself is REQUIRED, making the entire ensemble REQUIRED.

3.3.2 FieldObservation Report Type

3.3.2.1 Overview

The “FieldObservation” report type is used as a basic report that describes an observation that is directly observed by the reporter (an emergency professional), consisting of only four elements.

3.3.2.2 Field Observation Element Reference Model (Non-normative)

Figure 4 below 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.

Figure 4: EDXLSitRep ERM for FieldObservation Report 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.

3.3.3 SituationInformation Report Type

3.3.3.1 Overview

The “SituationInformation” report message type details the incident to which the current response is being mounted with elements such as IncidentName, IncidentType, IncidentComplexity and AffectedJurisdiction. SituationInformation intends to draw a concise and accurate picture of the situation.

3.3.3.2 SituationInformation Element Reference Model

Figure 5 below shows the SituationInformation report type Element Reference Model. The ERM shows the element-level details for the main entities in the SituationInformation report message type.

In addition, there are rules that apply to several elements that should be reviewed in the Message Rules section.

Figure 5: EDXLSitRep ERM for SituationInformation Message

The schema for a SituationInformation message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sr/v1.0/os/ and can be found in Appendix B.

3.3.4 ResponseResourcesTotals

3.3.4.1 Overview

The “ResponseResourcesTotals” report type is used to organize and report on the Resources needed or on hand for responding to the current incident.

3.3.4.2 ResponseResourcesTotals Element Reference Model

Figure 6 below 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.

Figure 6: EDXLSitRep ERM for ResponseResourcesTotalse Message

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.

3.3.5 CasualtyAndIllnessSummary Report Type

3.3.5.1 Overview

The “CasualtyAndIllnessSummary” report type is used to present a collection of vital data about the number and kind of casualties resulting from the incident.It is used by Incident Command to assess resource needs related to treating casualties and planning for associated needs such as Field Morgues, Field Hospitals, Temporary Shelters, etc.

3.3.5.2 CasualtyAndIllnessSummary Element Reference Model

Figure 7 below shows the CasualtyAndIllnessSummary report type Element Reference Model. The ERM shows the element-level details for the main entities in the CasualtyAndIllnessSummary report message type.

Figure 7 EDXLSitRep ERM for CasualtyAndIllnessSummary Message

The schema for a FieldObservation message is supplied separately at http://docs.oasis-open.org/emergency/edxl-sr/v1.0/os/ and can be found in Appendix B.

3.3.6 ManagementReportingSummary Report Type

3.3.6.1 Overview

The “ManagementReportingSummary” report type is used to compile, organize and report on various aspects of incident management information across responding organizations and up the chain of command.

3.3.6.2 Element Reference Model

Figure 8 below shows the ManagementReportingSummary report type Element Reference Model. The ERM shows the element-level details for the main entities in the ManagementReportingSummary report message type.

Figure 8: EDXLSitRep ERM for ManagementReportingSummary

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.

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” Elements

The following list of elements / information requirements are addressed through the OASIS EDXL-Distribution Element (DE) routing header (See Section 3.2 of this document for an explanation of each), which is used for routing and distribution of Situation information as well as other EDXL and non-EDXL payloads. The EDXL-SitRep standard is designed as a payload requiring use of a routing header, and specifically designed for use with the EDXL-Distribution Element (DE). The EDXL-DE is the required routing/distribution header for EDXL-SitReps unless an alternative routing header is available which meets all requirements of the EDXL-SitRep standard as specified in this section, and includes each element required of the EDXL-DE standard.

EDXL-SitRep Requirement	EDXL-DE Element(s)
Message Type	DistributionType
MessageSender	SenderID and SenderRole
SensitivityText	Confidentiality and combinedConfidentiality
ReleasabilityLevel	Confidentiality and combinedConfidentiality
Content Containers	“XMLcontent” and “nonXMLcontent” containers
SentDateTime	dateTimeSent
Signature	“nonXMLcontent” containers

4.2 IReport and Report Elements

The IReport element is the top level element in the EDXL-SituationReporting XML Schema provided separately and in Appendix Appendix B. The IReport element is specified as an abstract type.

<xs:complexType name="IReport" abstract="true"/>

This means that it cannot itself be used in an instance document. It must be instantiated by the element that is specifically defined to be its substitute, in this case, Report, as shown here:

<xs:element name="Report" type="IReport" minOccurs="1" maxOccurs="1"/>

Report can then be used to declare the Report Type of any given EDXL-SitRep message as shown here:

Element	IReport
Type	[AbstractType]
Usage	REQUIRED; MUST be used once and only once
Definition	Abstract Type used as the Type of the Report element which can then be used to declare an EDXL-SitRep message to be one of the five (5) predefined EDXL-SitRep “Reports” such as “FieldObservation”.
Comments	§ See Section 3.1.1 for diagrammatic representation of the relationship between IReport and Report
Constraints	IReport MUST NOT be used directly in any EDXL-SitRep message of any Report Type. It is part of the XML Schema against which implementations need to be validated.
Source	SitRep Use Cases
Requirements Supported	Message-Types

4.3 EDXLSitRepRoot Elements

The EDXL-SitRep message contains a set of core data which was transcribed from the Root element. In addition, it contains an element named “Report” of abstract type “IReport” where 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. Throughout this data dictionary, the concept of each of the five (5) specialized SitReps is referred to as an IReport “Report”.

The EDXLSitRepRoot element is the top level element of this specification, and contains the set of shared message elements used across the five (5) predefined EDXL-SitRep “Reports”. EDXLSitRepRoot elements identify and describe the EDXL-SitRep message with information such as MessageID, PreparedBy and ForTimePeriod

The five (5) distinct “Reports”, defined in Section 3.3.2 through 3.3.6, 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.

Element	MessageID
Type	ct:EDXLString
Usage	REQUIRED [1..1]
Definition	Each EDXL-SitRep contains an identifier that uniquely identifies the EDXL-SitRep message / Report.
Comments	§ The EDXL Distribution Element contains the "Distribution ID", which identifies the container for the distribution message information. § MessageID is the same element as used in EDXL-RM
Constraints	§ Used in EDXLSitRepRoot element / container
Source	SitRep Use Cases, EDXL-RM
Requirements Supported	MessageID

Element	PreparedBy
Type	ct:PersonTimePair
Usage	REQUIRED [1..1]
Definition	The person name and/or PositionTitle (ICSPositionTitle when an Incident Management Organization is in place) of the person preparing the information that makes up the message / report and the associated DateTime that this report was prepared
Comments	Note: The PreparedBy/Reporter/Originator may be different from the sender. Synonyms found in the NIMS SitRep: “Originator”, “Reporter”
Constraints	§ Used in EDXLSitRepRoot element / container
Source	ICS-209
Requirements Supported	Contact-Role-Enumerations, Report-DateTime-Information

Element	AuthorizedBy
Type	ct:PersonTimePair
Usage	REQUIRED [1..1]
Definition	The person name and/or PositionTitle (ICSPositionTitle when an Incident management Organziation is in place) of the person formally authorizing the information that makes up the message / report and the associated DateTime that this report was prepared
Comments	When an incident Management Organization is in place, this would be the Planning Section Chief or Incident Commander at the incident. On other incidents, it could be the jurisdiction's dispatch center manager, organizational administrator, or other manager.
Constraints	§ Used in EDXLSitRepRoot element / container
Source	ICS-209
Requirements Supported	Contact-Role-Enumerations, Report-DateTime-Information

Element	ReportPurpose
Type	ct:EDXLString
Usage	REQUIRED [1..1]
Definition	States the purpose of this Situation Report. May contain description information regarding why the report is being sent and required response or action, if any.
Comments
Constraints	§ Used in SitRep element / container
Source	Found in some local incident/situation reports.
Requirements Supported	Report Purpose

Element	ReportNumber
Type	ct:EDXLString
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
Source	ICS-209
Requirements Supported	Report-Number-Version

Element	ReportVersion
Type	ct:ValueList
Usage	REQUIRED [1..1]
Definition	This indicates the current version of the specific SitRep MessageReportType report being submitted from the same source (“AuthorizedBy”) for the same incident or event. If only one SitRep will be submitted, indicate BOTH “Initial” and “Final”. Default Code Values: § “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)
Comments
Constraints	§ Used in SitRep element / container
Source	ICS-209
Requirements Supported	Report-Number-Version

Note: The <dateTimeSent> element required in the EDXL-DE specification used to distribute any given EDXL-SitRep message satisfies the requirements for “SentDateTime” in the EDXL Situation Reporting v.1.0 Specification.

Element	ForTimePeriod
Type	ct:TimePeriod
Usage	REQUIRED [1..1]
Definition	ForTimePeriod designates the period of time between the FromDateTime and the ToDateTime elements whose definitions immediately follow this element defninition. ForTimePeriod is used by the ReportNumber and ReportVersion elements whose definitions immediate precede this element definition.. ForTimePeriod SHOULD include all of the time since the last SitRep “ReportNumber”/”ReportVersion” of this type was submitted. However, if this report is the originating EDXL-SitRep message for an incident, it should cover the time lapsed since the incident or event started. The ForTimePeriod element MUST include one operational period, but MAY also include more than one Operational Period based on agency/organizational reporting requirements. All elements of information contained in a given EDXL-SitRep message report type always apply only to the ForTimePeriod specified by the “FromDateTime” and the “ToDateTime”.
Comments
Constraints	§ Used in SitRep element / container
Source	ICS 203, 207, 209, 215
Requirements Supported	Report-DateTime-Information

Element	ReportTitle
Type	ct:EDXLString
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:"Report element.
Comments	Used to give a more particular title to an incident
Constraints	§ Used in SitRep element / container
Source	ICS-209
Requirements Supported	Report-Number-Version

Element	IncidentID
Type	ct:EDXLString
Usage	REQUIRED; MAY be used more than once [1..*]
Definition	The name or other identifier of the incident to which the current message refers, that has been assigned to the incident by an authorized agency based on current guidance.The incident number may vary by jurisdiction and profession (e.g. law enforcement vs. Fire). The incident number may be a computer aided dispatch number, an accounting number, a disaster declaration number, or a combination of the state, unit/agency, and dispatch system number. “Unknown” is an acceptable value.
Comments
Constraints	§ Used in SitRep element / container
Source	ICS 209 (“IncidentNumber”)
Requirements Supported	Incident-Identifier

Element	IncidentLifecyclePhase
Type	ct:ValueList [0..*]
Usage	OPTIONAL; MAY be used more than once
Definition	A code specifying the incident response lifecycle stage currently in effect
Comments
Constraints	§ Default enumerated values include: o Preparedness o Response o Mitigation o Recovery § Used in SitRep “SituationInformation” Report Type
Source
Requirements Supported	IncidentLifecyclePhase

Element	OriginatingMessageID
Type	ct:EDXLString
Usage	OPTIONAL [0..1]
Definition	Each EDXL-SitRep message contains a MessageID that uniquely identifies the message. OriginatingMessageID identifies the MessageID of the first message in a message sequence to which the message belongs. If the message is itself the originating message in a new sequence, OriginatingMessageID will have the same value as the MessageID element. In some other cases, the OriginatingMessageID element will have the same value as the PrecedingMessageID element. The OriginatingMessageID value essentially forms a unique identifier for a group of related messages, linking them together so that the relationship between the messages is made explicit and unambiguous (and threads of messages can be tracked by software).
Comments	§ Used to keep track of a string of related SitReps; especially given the fact that different jurisdictions may refer to the same incident or event in different ways and even define those different ways. § This MessageID is a SitRep MessageID, not an EDXL-Distribution Element MessageID. § Re-uses the same element as used in EDXL-RM § Should be included if known
Constraints	§ Used in SitRep element / container
Source
Requirements Supported	MessageID

Element	PrecedingMessageID
Type	ct:EDXLString
Usage	OPTIONAL; MAY be used once and only once. [0..*]
Definition	The PrecedingMessageID identifies the message that immediately preceded the current message in the message sequence. This MessageID is a SitRep MessageID not an EDXL-Distribution Element MessageID.
Comments	§ Typically SitReps are sequential from a given sender or authoritative source, but parallel SitReps will occur from several senders or sources. § This is particularly important given the fact that different jurisdictions may refer to the same incident or event in different ways and even define them differently.
Constraints	§ Used in SitRep element / container
Source
Requirements Supported	MessageID

Element	Urgency
Type	ct:ValueKey
Usage	OPTIONAL [0..1]
Definition	The code denoting the importance and necessity of the SitRep message
Comments	§ The “Urgency”, “Severity” and “ReportConfidence” elements collectively distinguish less emphatic from more emphatic messages. § Code Values (defaults) inherited from CAP 1.2 o “Immediate” - Responsive action SHOULD be taken immediately. o “Expected” - Responsive action SHOULD be taken soon (within next hour). o “Future” - Responsive action SHOULD be taken in the near future. o “Past” - Responsive action is no longer required. o “Unknown” - Urgency not known.
Constraints	§ Used in SitRep element / container
Source	SitRep Use Cases, Common Alerting Protocol (CAP)
Requirements Supported	Urgency

Element	ReportConfidence
Type	ct:ValueKey
Usage	REQUIRED [1..1]
Definition	The code denoting the level of confidence or sureness in the content of the EDXL-SitRep message, endorsed by the officer in the“AuthorizedBy” role.
Comments	· The “Urgency”, “Severity” and “ReportConfidence” elements collectively distinguish less emphatic from more emphatic messages. § Default enumerated values include: o “Highly Confident” – Topmost level of confidence. o “Somewhat Confident” – Medium level of confidence. o “Unsure” – Low level of confidence. o “No confidence” – Lack of confidence – Can be used to support cancellation of previous report
Constraints	§ Used in SitRep element / container
Source	SitRep Use Cases, Common Alerting Protocol (CAP)
Requirements Supported	ReportConfidence

Element	Severity
Type	ct:ValueKey
Usage	REQUIRED [1..1]
Definition	The code denoting the severity of the subject incident or event.
Comments	§ The “Urgency”, ”Severity” and “ReportConfidence” elements collectively distinguish less emphatic from more emphatic messages. § Re-uses the same element as used in EDXL CAP 1.2 § Default enumerated values inherited from CAP 1.2 include: o “Extreme” - Extraordinary threat to life or property. o “Severe” - Significant threat to life or property. o “Moderate” - Possible threat to life or property. o “Minor” - Minimal threat to life or property. o “Unknown” - Severity unknown
Constraints	§ Used in SitRep element / container
Source	SitRep Use Cases (not found in research, ICS or DHS forms)
Requirements Supported	Severity

Element	ReportingLocation
Type	ct:EDXLLocationType
Usage	OPTIONAL [0..1]
Definition	A structure representing the physical location and/or organization associated with the “PreparedBy” role, or associated with the location that the Field Observation is taking place, i.e. “where I am”.
Comments
Constraints	§ Used in SitRep element / container
Source
Requirements Supported	Incident-Resource-Operational-Planning, Incident-Resource-Commitment-Summary

Element	ActionPlan
Type	ct:EDXLString
Usage	OPTIONAL [0..1]
Definition	General description of what the officer in the “Prepared By” role needs or expects, or a description of intended next step(s) of Incident Command. ActionPlan is assumed to relate to the next operational period unless paired with a “StandardTimeFrame” defined by the user.
Comments	Synonyms of ActionPlan include “Way Forward,’” “Next Steps,” “Moving On”
Constraints	§ Used in SitRep element / container
Source	National Incident management System (NIMS)
Requirements Supported	Action-Plan

Element	NextContact
Type	ct:EDXLDateTime
Usage	OPTIONAL [0..1]
Definition	DateTime of next contact or report planned by the “Prepared By” role to set expectations for provision or receipt of updated or additional information.
Comments
Constraints	§ Used in SitRep element / container
Source	NIMS
Requirements Supported	Next-Contact

Element	Report
Type	IReport
Usage	REQUIRED; MUST be used once and only once [1..1]
Definition	Report is the element used to create an instance of the IReport abstract type and though 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: o FieldObservation o SituationInformation o ResponseResourcesTotals o CasualtyAndIllnessSummary o ManagementReportingSummary
Source	Used in the SitRep element / container
Requirements Supported

FieldObservation Report Type

The FieldObservation Report provides a basic Report Type intended for fast and flexible observation in the field by emergency response & management professionals, providing a collection of facts usually detected by human parties acting as mobile sensors and presented using plain text. Input sources will generally be mobile phones and other mobile devices.

The purpose of a Field Observation is to offer a standardized method of providing “on the ground” input from responders in the field. The intent is standardized receipt of Field Observations, which then may undergo verification and/or integration into formal Situation Reporting.

Element	FieldObservation
Type	EDXL-SitRep Report Type
Usage	OPTIONAL; MAY be used once and only once [0..1]
Definition	FieldObservation refers to directly observed phenomena in the field reported by the actual witness to the events reported in this EDXL-SitRep report message type.
Comments	This is an intentionally general report type meant to be reported as immediately and directly as possible. Speculation, even if based on experience is discouraged in this report type, so discussion of the past causes and future development are not specifically included. FieldObservation is intended to be quick and brief to expedite the quickest possible appropriate response.
Constraints	Used in EDXL-SitRep FieldObservation report type.
Source	Research, Experience
Requirements Supported	Flexibility

Element	ObservationLocation
Type	ct:EDXLLocationType
Usage	REQUIRED [1..1]
Definition	A 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. § Used in EDXL-SitRep FieldObservation report type
Source
Requirements Supported	Supporting Elements: Location Information

Element	ImmediateNeeds
Type	ct:EDXLString
Usage	REQUIRED [1..1]
Definition	A textual description of any pressing needs that the observer feels must be dispatched or provided urgently.
Comments	§ Intended to give advance notice of Resource Needs. § Not intended to replace EDXL-RM,
Constraints
Source
Requirements Supported	Coordination-with-EDXL-RM, Response-Resource-Information

Element	ImmediateNeedsCategory
Type	ct:ValueList
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	A category or classification of any pressing needs that the observer feels must be dispatched or provided urgently.
Comments
Constraints	§ Default enumerated values include: o Emergency Medical Services o Fire and Hazardous materials o Incident management o Law Enforcement o Mass Care o Public health o Public Works o Search and Rescue o CBRNE
Source
Requirements Supported	Coordination-with-EDXL-RM, Response-Resource-Information

Element	ObservationText
Type	[xsd:string]
Usage	REQUIRED [1..1]
Definition	Description of the situation being observed and reported.
Comments
Constraints
Source
Requirements Supported	Coordination-with-EDXL-RM, Response-Resource-Information

4.4 SituationInformation Report Type

The 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 Model (shown in Section 3.1)

§ 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.

Element	PrimaryIncidentInformation
Type	sr:IncidentInfoType
Usage	OPTIONAL [0..1]
Definition	The PrimaryIncidentInformation identifies and describes the initial incident.
Comments
Constraints	§ Used in SitRep “Situation Information” Report Type
Source	ICS 209
Requirements Supported	Incident-Identifier

Element	SubIncidentInformation
Type	sr:IncidentInfoType
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	The SubIncidentInfromation identifies and describes any subincident that occurs during, after, as a result of the initial incident or which is clearly connected to the initial incident but which is significant enough to require a separate report.
Comments
Constraints	§ Used in SitRep “Situation Information” Report Type
Source	ICS 209
Requirements Supported	Incident-Identifier

Element	SubIncident
Type	sr:IncidentInfoType
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	The SubIncidentInfromation identifies and describes any subincident that occurs during, after, as a result of the initial incident or which is clearly connected to the initial incident but which is significant enough to require a separate report.
Comments
Constraints	§ Used in SitRep “Situation Information” Report Type
Source	ICS 209
Requirements Supported	Incident-Identifier

4.4.1 IncidentInfoType Complex Type

IncidentInfoType elements identify the key items common to all incidents such as Name, Type, Complexity, etc.

Element	IncidentName
Type	[xsd: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
Source	ICS 201, 203, 207, 209, 215
Requirements Supported	Incident-Name; Incident-Identifier

Element	IncidentType
Type	ct:ValueList
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	General type or category of Incident.
Comments
Constraints	§ Default enumerated values inherited from EDXL-CAP CategoryType include: o Geo - Geophysical (inc. landslide) o Met - Meteorological (inc. flood) o Safety - General emergency and public safety o Security - Law enforcement, military, homeland and local/private security o Rescue - Rescue and recovery o Fire - Fire suppression and rescue o Health - Medical and public health o Env - Pollution and other environmental hazard o Transport - Public and private transportation o Infra - Utility, telecommunication, other non-transport infrastructure o CBRNE - Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or attack o Other - Other events § Used in SitRep “SituationInformation” Report Type
Source	DHS InitialSitRep, DHS Spot Report, ICS-209
Requirements Supported	Incident-Type

Element	IncidentComplexity
Type	ct:ValueList
Usage	OPTIONAL [0..1]
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 enumerated values include: Defaults: o “Complex” – Public / Professional preparedness is low, Coordination Complexity and involvement is high (local, regional, state and national) o “Moderate-Complex” – Public / Professional preparedness is moderate-high, Coordination Complexity and involvement is high (local, regional, state, possibly national). o “Moderate” – Public / Professional preparedness is high, Coordination Complexity and involvement is moderate (local, regional) o “Low” - Public / Professional preparedness is high, Coordination Complexity and involvement is low (local only) § Used in SitRep “Situation Information” Report type
Source	ICS 209, practitioners
Requirements Supported	Incident-Complexity

Element	IncidentStartDateTime
Type	ct:EDXLDateTime
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. o See Appendix Appendix C: Time Elements
Constraints	§ Used in SitRep “Situation Information” element / container
Source	ICS 209
Requirements Supported	Incident-Start-DateTime

Element	IncidentGeographicSize
Type	[xsd:unsignedLong]
Usage	OPTIONAL [0..1]
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
Source
Requirements Supported	Incident-Size

Element	IncidentLocation
Type	ct:EDXLLocationType
Usage	REQUIRED [1..1]
Definition	The physical location of the incident applying reusable EDXLLocationType components to express location information using a variety of options including geopolitical (e.g. addresses) and geospatial (e.g. lat/long).
Comments
Constraints	§ Used in SitRep “Situation Information” Report Type.
Source	ICS-209
Requirements Supported	Incident-Location

Element	DisasterInformation
Type	sr:DisasterInformation
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	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
Source	SitRep Use Cases
Requirements Supported	Incident-Identifer

Element	JurisdictionInformation
Type	sr:Jurisdiction
Usage	REQUIRED; MAY be used more than once (one for each Staging Area)
Definition	The physical location of each IncidentStagingArea applying reusable EDXLLocationTypecomponents to express location information using a variety of options including geopolitical (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
Source	ICS 209
Requirements Supported	Incident-Staging-Areas

Element	IncidentStagingAreaLocation
Type	ct:EDXLLocationType
Usage	OPTIONAL; 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 geopolitical (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
Source	ICS 209
Requirements Supported	Incident-Staging-Areas

4.4.2 DisasterInformation Complex Type

Element	DisasterName
Type	[xsd:string]
Usage	REQUIRED [1..1]
Definition	The name assigned to the disaster that is associated with this incident by the DisasterDeclarationAuthority. Part of the DisasterInformation XML structure.
Comments
Constraints	§ Used in SitRep “SituationInformation” Report Type
Source	SitRep Use Cases
Requirements Supported	Incident-Identifer

Element	DisasterDeclarationAuthority
Type	[xsd:string]
Usage	REQUIRED [1..1]
Definition	The organization, agency or authority that officially declared the disaster that is associated with this incident. Part of the DisasterInformation XML structure.
Comments
Constraints	§ Used in SitRep “SituationInformation” Report Type
Source	SitRep Use Cases
Requirements Supported	Incident-Identifer

Element	DisasterDeclarationDateTime
Type	ct:EDXLDateTime
Usage	REQUIRED [1..1]
Definition	The Date and Time a formal disaster is declared by an authority
Comments
Constraints	§ Used in SitRep “Situation Information” Report Type
Source	SitRep Use Cases
Requirements Supported	Report-DateTime-Information

4.5 ResponseResourcesTotals Report Type

The 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 by this structure. Totals are to be calculated by end applications.

Element	ResourceTotal
Type	sr:ResponseResourceTotals
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	The current total count (available inventory) of a given resource.
Comments
Constraints
Source
Requirements Supported	Response-Resource-Information

Element	OrganizationAndAssignments
Type	sr:CommandOrganization
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	IncidentCommand Structure documentation and Assignments
Comments
Constraints
Source
Requirements Supported	Incident-Command-Structure, Incident-Command-Organization

4.5.1 ResponseResourceTotals Complex Type

Element	BranchDivisionGroup
Type	ct:EDXLString
Usage	REQUIRED [1..1]
Definition	Name 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 / Category or Kind of resource
Comments	§ Supported by the edxl-ciq [XML Structure]
Constraints	§ Used in EDXL-SitRep ResponseResourceTotals Report Type.
Source	ICS 215
Requirements Supported	Incident-Resouce-Commitment; Incident-Resource-Operational-Planning; Incident-Command-Organization

Element	Resource
Type	sr:ResourceCount
Usage	REQUIRED; MAY be used more than once [1..*]
Definition	Specific individual named resource,
Comments
Constraints
Source
Requirements Supported

4.5.2 ResourceStatus Complex Type

Resource Statuselements provide inventory, deployment and availability information.

Element	InventoryRefreshDateTime
Type	ct:EDXLDateTime
Usage	REQUIRED [1..1]
Definition	The DateTime at which inventory records were last updated with current values.
Comments
Constraints	§ Used in EDXL-SitRep ResponseResourceTotals Report Type.
Source
Requirements Supported	Incident-Resouce-Commitment; Incident-Resource-Operational-Planning; Incident-Command-Organization

Element	Availability
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Availability provides information on whether or not a resource is available, and any incidental information not otherwise provided that relates to resource availability.
Comments
Constraints
Source
Requirements Supported	Incident-Resouce-Commitment; Incident-Resource-Operational-Planning; Incident-Command-Organization

Element	DeploymentStatus
Type	ct:ValueListType
Usage	OPTIONAL [0..1]
Definition	The DeploymentStatus element is a value corresponding to the value for a ValueListType supplied by the resource provider.
Comments
Constraints
Source
Requirements Supported	Incident-Resouce-Commitment; Incident-Resource-Operational-Planning; Incident-Command-Organization

Element	DeploymentStatusDefault
Type	ct:DeploymentStatusDefaultType
Usage	OPTIONAL [0..1]
Definition	Default enumerated values o Available o ConditionallyAvailable o Enroute o AtHospital o NotAvailable o OnScene o Overdue o AvailablebyPager o InQuarters o OntheRadio o Transporting o WaitingResponse
Comments
Constraints
Source
Requirements Supported	Incident-Resouce-Commitment; Incident-Resource-Operational-Planning; Incident-Command-Organization

4.5.3 ResourceCount Complex Type

Element	AgencyOrganization
Type	ct:EDXLString
Usage	REQUIRED [1..1]
Definition	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 function, or a nongovernmental organization (e.g., private contractor, business, etc.) that offers a 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.
Source	ICS-209, 215j
Requirements Supported	Incident-Resource-Commitment; Incident-Resource-Operational-Planning;Incident-Command-Organization

Element	ResourceName
Type	ct:EDXLString
Usage	REQUIRED [1..1]
Definition	A name or title of the resource used for identification and tracking.
Comments
Constraints	§ Used in EDXL-SitRep ResponseResourcesTotals Report Type.
Source	ICS 209
Requirements Supported	Response Resources-Information

Element	ResourceTypeCategoryKind
Type	ct:ValueList
Usage	OPTIONAL [0..1]
Definition	Short reference to the name of the resource type, category or kind associated with the resource name.
Comments	§ 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: o Fixed wing cargo aircraft o Mobile Field Kitchen / Type II / Food & Water o “Decontamination” unit o Type 1 Fire Engine o Type 4 Helicopter
Constraints	§ Used in EDXL-SitRep ResponseResourcesTotals Report Type.
Source	ICS 209
Requirements Supported	Response Resources-Information

Element	ResourceDetail
Type	sr:ResponseResourcesDetail
Usage	OPTIONAL [0..1]
Definition	Summary information, often rendered in “counts” about resources involved in emergency operations.
Comments
Constraints
Source
Requirements Supported	Response-Resource-Information

Element	IsSufficient
Type	[xsd:boolean]
Usage	OPTIONAL [0..1]
Definition	A “yes” or “no” value indicating whether or not a given resource is sufficient to fill current or projected requirements.
Comments
Constraints
Source
Requirements Supported	Response-Resource-Information

4.5.4 ResponseResourcesTotalsDetail Complex Type

The “ResponseResourcesDetail” Report Type package contains counts for each specific type, category or kind of responding resource required, committed, on-hand, requested or still needed; in order to manage and coordinate resource decisions. IF “ResponseResourceTotals” is used, at least one “ResponseResourcesTotalsDetail” is Required, AND a value entered for at least one associated element (i.e. at least one value included such as “ResourceRequiredCount”)

§ 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.

§ “Response Resource Detail” also utilizes the following supporting elements:

o EDXLLocationType [XML Structure]

Element	ResourcePersonnelCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [0..1]
Definition	The personnel associated with or required to operate each required resource by “Type/Category/Kind” provided by an “Agency or Organization
Comments
Constraints	§ Used in EDXL-SitRep ResponseResourcesTotals Report Type.
Source
Requirements Supported	Incident-Resource-Commitment-Summary

Element	UnassignedResourcePersonnel
Type	[xsd:unsignedInt]
Usage	OPTIONAL [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
Source
Requirements Supported	Incident-Resource-Commitment-Summary

Element	ResourceRequiredCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [1..1]
Definition	The number of resources by “Type/Category/Kind” provided by an “Agency or Organization”, required to meet a specified need or work assignment.
Comments
Constraints	§ Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Source	ICS 209
Requirements Supported	Incident-Resource-Commitment-Summary

Element	ResourceCommittedCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [1..1]
Definition	The number of resources by “Type/Category/Kind” provided by an “Agency or Organization”, committed to meet the specified need or work assignment. “Committed” refers to an obligation 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
Source	ICS 209
Requirements Supported	Incident-Resource-Commitment-Summary

Element	ResourceOnHandCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [1..1]
Definition	The number of resources by “Type/Category/Kind” provided by an “Agency or Organization”, 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
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	ResourceStillNeededCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [1..1]
Definition	The number of resources by “Type/Category/Kind” provided by an “Agency or Organization”, still needed to meet a specified need or work assignment. “Needed” refers to resources 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
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	ResourceRequestedCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [1..1]
Definition	The number of resources by “Type/Category/Kind” provided by an “Agency or Organization”, that has been requested or ordered in order to meet a specified need or work assignment.
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
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	DateTimeOrdered
Type	ct:EDXLDateTime
Usage	OPTIONAL [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
Source	ICS 201
Requirements Supported	Incident-Resource-Operational-Planning

Element	RequestedArrival
Type	ct:EDXLDateTime
Usage	OPTIONAL [0..1]
Definition	The DateTime when the “requested” / “ordered” resource is requested to arrive at the “ReportingLocation” (i.e. When the resource is needed).
Comments	§ ICS uses the term "delivery" vs. "arrival". “Arrival" is used here because this applies to Human Resources also Note: In EDXL-RM, “RequestedArrival” is an enumerated value of element “ScheduleType”
Constraints	§ Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	EstimatedArrival
Type	ct:EDXLDateTime
Usage	OPTIONAL [0..1]
Definition	The DateTime when the “requested” / “ordered” resource is expected to arrive at its “ReportTo” location.
Comments	Note: In EDXL-RM, “EstimatedArrival l” is an enumerated value of element “ScheduleType”
Constraints	§ Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	ReportToLocation
Type	ct:EDXLLocationType
Usage	OPTIONAL [0..1]
Definition	The location where the resources are to report or be delivered (e.g. “IncidentStagingArea”, “IncidentLocation”).
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
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	OverheadPosition
Type	ct:ValueKeyIntPair
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: o Division Supervisor o Group Supervisor o Assistant Safety Officer o Techncal Specialst
Constraints	§ Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	WorkAssignment
Type	ct:EDXLString
Usage	OPTIONAL [0..1]
Definition	Description of the anticipated work assignments given to the resource.
Comments
Constraints	§ Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Source	ICS 215
Requirements Supported	Incident-Decision-Support-Instructions; Incident-Command-Organization

Element	SpecialInstructions
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Description of any special instructions to the resource regarding their assignment, reporting location or any other instructions.
Comments
Constraints	§ Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Source	ICS 215
Requirements Supported	Incident-Decision-Support-Instructions; Incident-Command-Organization

Element	SpecialEquipmentAndSupplies
Type	[xsd:string]
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	For each “Branch/Division/Group/Location” / “WorkAssignment/SpecialInstructions” combination, a listing of special equipment or supplies needed.
Comments
Constraints	§ Used in EDXL-SitRep “ResponseResourcesTotalsDetail” element group
Source	ICS 215
Requirements Supported	Incident-Resource-Operational-Planning

Element	AdditionalAssistingOrganizations
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	A list of all other agencies and organizations that are not included in the formal “ResponseResource” 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
Source	ICS 209
Requirements Supported	Incident-Resource-Commitment-Summary

4.5.5 CommandOrganization Complex Type

Incident Organization & Assignments is a component of the “ResponseResourcesTotals” ReportType, providing a hierarchical XML organization structure including information on the names, titles, assignments, 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 agencies and up the chain of command, such that end applications may if desired create or populate an incident 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:

§ EDXLLocationType [XML Structure]

§ Remarks

Element	CommandStructure
Type	ct:EDXLString
Usage	OPTIONAL [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 Command”), 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 contains reference to the incident or disaster name. The overall structure contains the Positions, Names, Agency, Branch, and “Report-To” relationships required to share incident organization information as needed across agencies and up the chain of command, such that end applications may if desired create or populate an incident command structure chart. Incident Command structure and personnel may change over the course of an incident, or shifts 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
Constraints
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization, Incident-Organization-and-Assignments

Element	PositionTitle
Type	ct:ValueKeyStringPair
Usage	OPTIONAL [0..1]
Definition	A position name, role name or title of a professional that may fall at any level of the Incident Command Structure hierarchy
Comments	§ Enumerated default values include: o Incident Commander o Liaison Officer o Communications Officer o Safety Officer o Public Information Officer o Technical Specialst o Planning Section Chief o Situation Unit Leader o Resources Unit Leader o Documentation Unit Leader o Demobilization Unit Leader o Operations Section Chief o Staging Area Manager o Logistics Section Chief o Support Branch Director o Supply Unit Director o Facilities Unit Director o Ground Support Unit Leader o Service Branch Director o Food Unit Leader o Medical Unit Leader o Communications Unit Leader o Finance & Administration Section Chief o Cost Unit Leader o Time Unit Leader o Procurement Unit Leader o Compensation & Claims Unit Leader § Additional elements that may be included with each PositionTitle (defined below) include: o PersonName o Agency o Branch o ReportToPositionTitle o ReportToPersonName o ReportToAgency o ReportToBranch
Constraints
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization

Element	PersonName
Type	ct:PersonDetails
Usage	OPTIONAL [0..1]
Definition	An agency is a type of organization, which is a division of government with a specific function, or a nongovernmental organization (e.g., private contractor, business, etc.) that offers a 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 Multi-agency.)
Comments	§ Agencies may be listed individually or in groups.
Constraints
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization

Element	Branch
Type	ct:ValueKey
Usage	OPTIONAL [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
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization

Element	ReportsToPositionTitle
Type	ct:ValueKey
Usage	OPTIONAL [0..1]
Definition	A position name, role name or title of a professional that the current PositionTitle Value reports to in the Incident Command Structure hierarchy
Comments	§ Default enumerated values include:: (Same ValueList as PositionTitle) o Incident Commander o Liaison Officer o Communications Officer o Safety Officer o Public Information Officer o Technical Specialst o Planning Section Chief o Situation Unit Leader o Resources Unit Leader o Documentation Unit Leader o Demobilization Unit Leader o Operations Section Chief o Staging Area Manager o Logistics Section Chief o Support Branch Director o Supply Unit Director o Facilities Unit Director o Ground Support Unit Leader o Service Branch Director o Food Unit Leader o Medical Unit Leader o Communications Unit Leader o Finance & Administration Section Chief o Cost Unit Leader o Time Unit Leader o Procurement Unit Leader o Compensation & Claims Unit Leader § Additional elements that may be included with each ReportsToPositionTitle include: o ReportsToPersonName o ReportsToAgency o ReportsToBranch
Constraints
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization

Element	ReportsToPersonName
Type	ct:PersonDetails
Usage	OPTIONAL [0..1]
Definition	Name of the person filling the ReportsToPositionTitle or role within the Incident Command Structure hierarchy
Comments
Constraints
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization

Element	ReportsToAgency
Type	ct:ValueList
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	An agency is a type of organization, which is a division of government with a specific function, or a nongovernmental organization (e.g., private contractor, business, etc.) that offers a 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 Multi-agency.)
Comments
Constraints
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization

Element	ReportsToBranch
Type	ct:ValueKey
Usage	OPTIONAL [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
Source	ICS 201, ICS 203
Requirements Supported	Incident-Command-Organization

4.6 CasualtyAndIllnessSummary Report Type

The “Casualty and Illness Summary” ReportType provides casualty numbers and percentages by prescribed categories over specified time periods. Casualty information categories are further segregated by responders (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 “Ttotals”. totals can be calculated, so separate elements for those values are not included

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.

Element	SummaryCount
Type	sr:CasualtyAndIllnessCategory
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition
Comments
Constraints
Source
Requirements Supported	Casualty-and-Illness-Summary

Element	NotifiableDiseaseNumbers
Type	sr:NotifiableDiseaseNumbers
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition
Comments
Constraints
Source
Requirements Supported	Casualty-and-Illness-Summary

4.6.1 CasualtyAndIllnessCategory Complex Type

The CasualtyAndIllnessSummary Report Type as a whole is optional. However, if any one or more elements from the CasualtyAndIllnessSummary Element Group is completed, then a full report MUST be created 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.

Element	CasualtyAndIllnessCountCategory
Type	ct:ValueKeyType
Usage	REQUIRED [1..1]
Definition	A type of casualty or illness, used to collect counts and statistics by types of casualties. Part of the CasualtyAndIllnessSummaryCount XML structure.
Comments	A casualty is any person impacted in some way by an emergency situation or disaster.
Constraints	§ Default enumerated values include:: o Fatality – Deceased o Hospitalized – In-route or arrived at an Emergency Department or Hospital o Injury / Illness – 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. o Trapped / In Need of Rescue – In need of rescue due to incident or other conditions o Missing – Cannot be located o Evacuated – Accounted for and being evacuated from the scene o Sheltering in Place – Accounted for but sheltering in their original location at time of the incident o In Temporary Shelters – Accounted for and have been placed in a temporary shelter o In Quarantine – Accounted for and under quarantine by authorities § Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

Element	ResponderSummaryCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL[0..1]
Definition	For each CasualtyAndIllnessCountCategory, the count of Responder Casualties for this reporting 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
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

Element	NonResponderSummaryCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [0..1]
Definition	For each CasualtyAndIllnessCountCategory, the count of Non-Responder Casualties for this reporting period. 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”.)
Constraints	§ Used in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

Element	ResponderSummaryCountToDate
Type	[xsd:unsignedInt]
Usage	OPTIONAL [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.
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

Element	NonResponderSummaryCountToDate
Type	[xsd:unsignedInt]
Usage	OPTIONAL [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.
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

Element	HaveReceivedMassImmunizationsCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [0..1]
Definition	The number count of people who have received immunizations relevant specifically to incident 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.
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

Element	RequireMassImmunizationsCount
Type	[xsd:unsignedInt]
Usage	OPTIONAL [0..1]
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.
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

Element	ShelterCountEstimate
Type	[xsd:unsignedInt]
Usage	OPTIONAL [0..1]
Definition	The total number of people projected to require shelter due to the incident, to assist planning 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.
Source	ICS 209
Requirements Supported	Casualty-and-Illness-Summary

4.6.1.1 NotifiableDiseaseNumbers Complex Type

A notifiable disease is one for which regular, frequent, timely information on individual cases is considered necessary to prevent and control that disease.

Can re-use the common element “estimated”…

Element	DiseaseSuspected
Type	ct:ValueKey
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 reviewed 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
Source
Requirements Supported	Notifiable-Disease-Numbers

Element	ProbableCause
Type	ct:EDXLString
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
Source
Requirements Supported	Notifiable-Disease-Numbers

Element	CountOfSuspectedCases
Type	[xsd:unsignedInt]
Usage	REQUIRED [1..1]
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
Source
Requirements Supported	Notifiable-Disease-Numbers

Element	CountOfConfirmedCases
Type	[xsd: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
Source
Requirements Supported	Notifiable-Disease-Numbers

4.7 ManagementReportingSummary Report Type

The ManagementReportingSummary Report Type contains elements to manage information related to situation 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 conern 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..

Element	SituationSummary
Type	sr:SituationSummary
Usage	OPTIONAL [0..1]
Definition	The element group gathered in SituationSummary identifies situation status and descrbes information aimed, primarily as support for human decision-making across the organizations involved and within the chain of command . SituationSummary focuses on information about infrastructure and Primary Hazards, Threat to Human Life and Safety,I nfrastructure Affected and Possible Cascading Effects.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

Element	DecisionSupportInformation
Type	sr:IncidentDescionSupportInformation
Usage	OPTIONAL [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 presented to incident command with as much analysis as time allows throughout the lifecycle of the incident and response.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

Element	JurisdictionInformation
Type	sr:Jurisdiction
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	JurisdictionInformation provides key information about incident command and the various organizations involved in the response. Jurisdiction INformaiton is key to making quick decisions that do not exceed the authority of the jurisdiction involved.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

4.7.1 ExternalAffairs Complex Type

The ExternalAffairs element group provides information about concerns that are external to the ManagementReportingSummary context that nevertheless needs to be taken into account by the responder organizations and jurisdictions.

Element	EffectivePublicCommunication
Type	[xsd:boolean]
Usage	OPTIONAL [0..1]
Definition	The EffectivePublicCommunication element is aimed at gauging whether or not the responding agency is communicating well with the at-risk public as well as the public at large.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

Element	TalkingPoints
Type	{XML Structure]
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	TalkingPoints is the container element for individual Talking Points.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

Element	TalkingPoint
Type	[xsd:string]
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	TalkingPoint 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.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

Element	Rumors
Type	{XML Structure]
Usage	OPTIONAL [0..1]
Definition	Rumors is the container element for individual Rumor elements.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

Element	Rumor
Type	[xsd:string]
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	Rumort 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.
Comments
Constraints
Source
Requirements Supported	Incident-Response-Information

4.7.2 SituationSummary Complex Type

The 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, Infrastructure Affected and Possible Cascading Effects.

Element	IncidentCause
Type	[xsd:string]
Usage	REQUIRED [1..1]
Definition	The known or suspected cause of the incident such as "tornado", "wildfire", "bridge collapse", "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
Source	ICS 209
Requirements Supported	Situation-Summary-Information Information Requirement #28

Element	SignificantEvents
Type	ct:ValueList
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	This element provides a list (ValueKey: xsd:AnyURI) of SignificantEvent(s), each associated with a value. The value is a string providing a textual description summarizing significant results, decisions or progress resulting from an incident such as, evacuations, incident 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 closures include road number and duration of closure.
Comments	§ Re-uses the element “Remarks” to include specifics § Default enumerated values include, but are not limited to the following o Road closure o Mass Notifications o Evacuation o Shelter in place o Road Closure o Power outage o Tree(s) down o Stranded vehicle(s) o Water Line break o Water shortage o Quarantine o Bridge collapse o Building collapse o Deaths o Injuries o Mass Immunizations o Cleanup Complete o Resident repopulation o Incident Command Transition o Accomplishments
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	DamageAssessmentInformation
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Textual description summarizing damage and/or restriction of use/availability to residential or 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.
Comments
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	PrimaryHazards
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Textual description summarizing hazardous chemicals, fuel types, infectious agents, radiation, etc. When relevant includes the appropriate primary materials, fuels or other hazards involved in the incident that are leaking, burning, infecting or otherwise causing major problems. Examples include hazardous chemicals, wildland fuel models, biohazards, explosive materials, oil, gas etc.
Comments
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	ICS 209
Requirements Supported	§ Situation-Summary-Information

Element	HazMatIncidentReport
Type	xs:any
Usage	OPTIONAL [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 Existing HazMat Structures may be used.
Comments
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	SitRep Used Cases
Requirements Supported	Situation-Summary-Information

Element	ExtentOfContamination
Type	ct:EDXLLocationType
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	The geographical extent or “footprint” of the Contamination
Comments
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation-Summary-Information

Element	GeneralPopulationStatus
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	General status description of the general population in designated counties during emergencies or disasters.
Comments
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation-Summary-Information

Element	HumanLifeAndSafetyThreat
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Textual description of hazards which are potentially dangerous and cause a threat to human 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
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	LifeAndSafetyThreat
Type	ct:ValueList
Usage	REQUIRED; MAY be used more than once [0..*]
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
Constraints	§ Default enumerated values include but is not limited to: o No Likely Threat - No likely threat to life and safety. o Potential Future Threat - Potential future threat to life and safety. o Mass Notifications In Progress - 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 Emergency Alert System or a “reverse 911” system. o Mass Notifications Completed – “Casualty and Illness Summary” by Responder has been completed and submitted for this “ForTimePeriod” o No Evacuation(s) Imminent - Evacuations are not anticipated in the near future based on current information. o Planning For Evacuation - Evacuation planning is underway in relation to this incident. o Planning For Shelter-In-Place - Planning is underway for shelter in place activities related to this incident. o Evacuation(s) In Progress - There are active evacuations in progress relating to this incident. o Shelter-In-Place In Progress - There are active shelter- in-place actions in progress relating to this incident. o Repopulation In Progress - There is an active repopulation in progress relevant to this incident. o Mass Immunization In Progress - There is an active mass immunization in progress relevant to this incident. o Mass Immunization Complete - A mass immunization effort has been completed in specific relation to this incident. o Quarantine In Progress - There is an active quarantine in progress relative specifically to this incident. § 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
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	IncidentThreatSummaryAndRisk
Type	[xsd:string]
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	A 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.
Comments	Note: 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
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	FollowOnIndication
Type	[xsd:string]
Usage	OPTIONAL [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
Source
Requirements Supported	Situation-Summary-Information

Element	InfrastructureAffected
Type	ct:ValueKeyStringPair
Usage	OPTIONAL; MAY be used more than once [0..*]
Definition	Infrastructure and/or operational systems actually or most likely affected by disaster.
Comments	Note: The purpose of this element is similar to the purpose of the threat element above and in IncidentDecisionSupportInformation
Constraints	§ Default enumerated values includeThe enumerated list of default values includes but is not limited to: o Mass Transit o Roads and Highways o Railway o Bridges and Tunnels o Seaports o Waterways o Airports o Broadcast (TV, Radio, etc.) o Power o Water o Bridges o Gas Lines o Nuclear o Conduits and raceways o Cabling, patch panels o Power & Energy o Air Conditioning o Drinking Water o Sewage o Irrigation o Waste / Hazardous Waste o Flood control (dikes, Levees) o Earth monitoring and measurement networks (Tidal, Meteorological, Seismoneter, etc.) o Postal o Telecommunications – Phone o Telecommunications – Mobile o Internet backbone o Private Network o Satellite o Electronic Communications Networks o Personal Computing servers and devices o Trained Personnel o Used in SitRep “Situation Summary” element / container
Source
Requirements Supported	Situation-Summary-Information

Element	PropertyDamage
Type	ct:ValueKeyIntPair
Usage	OPTIONAL; MAY use mutltiple [0..*]
Definition	The number of property categories that are threatened, damaged or destroyed by disaster or incident.
Comments
Constraints	§ Always paired with one “PropertyCategory” § Value list defaults include but not limited to: o Threatened within 72 hours o Damaged o Destroyed o Value (numeric designating the number threatened, damaged or destroyed) § Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation-Summary-Information

Element	PercentContained
Type	ct:Percentage
Usage	OPTIONAL [0..1]
Definition	Estimated percentage of the incident that has been contained, or where work to complete response to the incident has been completed.
Comments	e.g. 80%
Constraints	Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation-Summary-Information

Element	RequestsForAdditionalSupport
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	General description or summary of requests for additional resources or personnel – high-level textual summary of “Response Resources”.
Comments	Note: EDXL-RM messages may be referred to, or used to provide this and/or more detailed information.
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation-Summary-Information

Element	TerrorismNexus
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Textual descripton 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
Source
Requirements Supported	Situation-Summary-Information

Element	WeatherEffects
Type	ct:WeatherInfo
Usage	OPTIONAL [0..1]
Definition	Text indicating Current and predicted weather and related factors that may effect or cause concern for the incident and related areas, in the form of a short synopsis on weather factors.
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. § Includes, but not limited to: o Wind Speed (label units, such as mph). o Wind Direction (clarify and label where wind is coming from and going to in plain language, i.e.: “from NNW”, “from E”, or “from SW”). o Temperature (label units such as F) o Relative Humidity (label %) o Watches o Warnings o Tides o Currents
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	WMDEffects
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Textual descripton of any effects produced by weapons of mass destruction.
Comments
Constraints	§ Used in EDXL-SitRep SituationSummary element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation-Summary-Information

Element	TransportationSystems
Type	ct:ValueKeyStringPair
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
Source	ICS 209
Requirements Supported	Situation Summary-Information

4.7.3 DebrisManagement ComplexType

Elements in the DebrisManagement ComplexType are used to track the details of debris management.in the incident being reported.

Element	TotalDebrisGeneratedCY
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [0..1]
Definition	TotalDebrisGeneratedCY stands for Total Debris Generated 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
Source
Requirements Supported	Situation Summary-Information

Element	DebrisClearedToDateCY
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [0..1]
Definition	DebrisClearedToDateCY stands for Debris Cleared To Date 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
Source
Requirements Supported	Situation Summary-Information

Element	DebrisNotYetClearedCY
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [0..1]
Definition	DebrisNotYetClearedCY stands for DebrisNotYetCleared 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
Source
Requirements Supported	Situation Summary-Information

Element	DaysToClearanceComplete
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [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
Source
Requirements Supported	Situation Summary-Information

Element	PercentOfJurisdictionWithDebrisImpacts
Type	[ct:percentageType]
Usage	OPTIONAL, [0..1]
Definition	PercentOfJurisdictionWithDebrisImpacts 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
Source
Requirements Supported	Situation Summary-Information

Element	AreasWithDebrisImpacts
Type	[ct:ValueListType]
Usage	OPTIONAL, [0..1]
Definition	AreasWithDebrisImpacts stands for areas named in the ValueListType within the Jurisdiction in the Incident being reported which have Debris Impacts.
Comments
Constraints	§ Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation Summary-Information

Element	AreasWhereWorkNotStarted
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [0..1]
Definition	AreasWhereWorkNotStarted stands for areas named in the ValueListType within the Jurisdiction in the Incident being reported where work has begun on Debris Removal.
Comments
Constraints	§ Used in EDXL-DebrisManagement ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
Source
Requirements Supported	Situation Summary-Information

Element	DebrisDisposedToDateCY
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [0..1]
Definition	DebrisDisposedToDateCY stands for Total Debris 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
Source	ICS 209
Requirements Supported	Situation Summary-Information

Element	DebrisNotYetDisposedCY
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [0..1]
Definition	DebrisNotYetDisposedCY stands for Total Debris that has not yet been disposed ofin 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
Source
Requirements Supported	Situation Summary-Information

Element	DebrisStorageSitesPercentFilled
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [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
Source
Requirements Supported	Situation Summary-Information

Element	DaysToDisposalComplete
Type	[xsd:unsignedInt]
Usage	OPTIONAL, [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 ManagementReportingSummary Report Type
Source
Requirements Supported	Situation Summary-Information

4.7.4 IncidentDecisionSupportInformation ComplexType

Elements in the IncidentDecisionSupportInformation 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:

§ LocationSizeUOM

§ StandardTimeFrames

§ Remarks

Element	ProjectedIncidentActivity
Type	ct:ValueKeyStringPair
Usage	OPTIONAL [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 period. Direction/scope in which the incident is expected to spread, migrates, or expands during the next operational period, or other factors that may cause activity changes.
Comments	§ Include 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
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	ProjectedNumberToBeSheltered
Type	[xsd:unsignedInt]
Usage	OPTIONAL [0..1]
Definition	The total number of people projected to require shelter due to the incident, to assist planning 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
Source
Requirements Supported	Incident-Decision-Support-Information

Element	CriticalResourceNeeds
Type	ct:ValueKeyStringPair
Usage	OPTIONAL, MAY be used more than once [0..*]
Definition	A summary of the overall resource needs required over 12-, 24-, 48- and 72-hour time frames, and anticipated after 72-hours.
Comments	§ Used in conjunction with the “StandardTimeFrames” element (ValueListURN).
Constraints	§ Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	ProjectedFinalIncidentSize
Type	[xsd:unsignedLong]
Usage	OPTIONAL [0..1]
Definition	An estimate of the total physical area likely to be involved or affected over the course of the incident.
Comments	§ Use labels for acres, hectares, square miles, etc., as appropriate (Use the “LocationSizeUOM” element). § Though both came from ICS-209, need to be clear difference and purpose vs. “Incident Size”. Note that Incident Size may be actual or estimated.
Constraints	§ Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	AnticipatedCompletionDate
Type	ct:EDXLDateTime
Usage	OPTIONAL [0..1]
Definition	The Date/Time at which incident containment or control is expected, or at which time the incdent 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
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	ProjectedDemobilizationStartDate
Type	ct:EDXLDateTime
Usage	OPTIONAL [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
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	EstimatedCostsToDate
Type	ct:Currency
Usage	OPTIONAL [0..1]
Definition	An estimate of the total costs for the incident once all financial costs have been processed based 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
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	ProjectedFinalCosts
Type	ct:Currency
Usage	OPTIONAL [0..1]
Definition	An estimate of the total costs for the incident once all financial costs have been processed based 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
Source	ICS 209
Requirements Supported	Incident-Decision-Support-Information

Element	EmergencyResponseIssues
Type	ct:ValueKeyStringPair
Usage	OPTIONAL (MAY be used more than once)
Definition	Brief overview of current and critical response activities, and initiatives for each Emergency 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.
Comments
Constraints	§ Enumerated default values include the following, a proposed list of ESF’s (taken from NIMS and the DHS SitReps): o (ESF11) AgricultureAndNaturalResources o (ESF2) Communications o (ESF5) EmergencyManagement o (ESF12) Energy o (ESF15) ExternalAffairs o (ESF4) Firefighting o (ESF7) LogisticsManagementResourceSupport o (ESF14) LongTermCommunityRecoveryAndMitigation o (ESF6) MassCareHousingAndHumanServices o (ESF10) OilAndHazardousMaterialsResponse o (ESF8) PublicHealthAndMedicalServices o (ESF13) PublicSafetyAndSecurity o (ESF3) PublicWorksAndEngineering o (ESF9) SearchAndRescue o (ESF1) Transportation · Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	DHS SitRep Update Report, DHS/FEMA SitRep Worksheet
Requirements Supported

Element	StrategicDiscussion
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Discussion of planned activities over the next operational period, explaining the relation of 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 management 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
Source	DHS SitRep Update Report, DHS/FEMA SitRep Worksheet
Requirements Supported

Element	PlannedActions
Type	[xsd:string]
Usage	OPTIONAL [0..1]
Definition	Discussion of planned actions over the next operational period.
Comments
Constraints	Used in EDXL-SitRep IncidentDecisionSupportInformation element group within the EDXL-SitRep ManagementReportingSummary Report Type
Source	DHS SitRep Update Report, DHS/FEMA SitRep Worksheet
Requirements Supported

4.8 Supporting Elements Model

Supporting Element Types borrow re-usable elements from the edxl-rim collection that apply to and support multiple areas of the SitRep messages; examples of such elements: Locations, Contacts and Roles, and Unit of Measure. They rely on different collections. For instance Locations are of type EDXLLocationType, which is defined in the CommonTypes collection (hosted at http://docs.oasis-open.org/emergency/edxl-ct/v1.0/csd01/), which itself relies on the EDXL-CIQ profile (hosted at http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/csd01/) for geopolitical info and on the EDXL-GSF profile (not yet hosted) for geographical information.

The Supporting Elements Model distinguishes three groups of elements: CommonTypes (edxl-ct), ContactInformation (edxl-ciq) and LocationInformation (edxl-gsf).

The following elements are used in this specification and can be found at the locations cited above.:

Supporting Element	Defined in
EDXLLocationType	edxl-ct
EDXLGeoLocationType	edxl-gsf
EDXLGeoPoliticalLocationType	edxl-ciq
ValueListURI	edcl-ct
Value	edxl-ct
ValueListIntPairType	edxl-ct
ValueListStringPairType	edxl-ct
Estimate	edxl-ct
Remarks	edxl-ct

4.9 JurisdictionInformation Elements

“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.

Element	Jurisdiction
Type	[XML Structure][xsd:string]
Usage	OPTIONAL [0..1]
Definition	An XML structure containing the following four required elements: § Name § GeographicSize § Location § Description Provides information about any jurisdiction(s) that are associated with, impacted by or in charge of this incident.
Comments
Constraints
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	Name
Type	[xsd:string]
Usage	REQUIRED [1..1]
Definition	The name of the jurisdiction (a pre-defined physical location or geo-political area, organization or agency over which legal authority extends) affected by the incident, where the incident originated, or which holds certain authority within its own jurisdiction as well as authority 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: o Reference to an organization or agency that has “Authority” over something (such as an incident, or a set of identified resources). Jurisdiction in this sence 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”. o 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.
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	Size
Type	[xsd:unsignedLong]
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.
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	Location
Type	edxl-gsf [XML Structure]
Usage	REQUIRED [1..1]
Definition	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.
Source	ICS 209
Requirements Supported	Situation-Summary-Information

Element	Description
Type	[xsd:string]
Usage	REQUIRED [1..1]
Definition	A textual descripton of the “AffectedJurisdictionName” which may provide further information about the incident effects on that Jurisdiction and/or description of the AffectedJurisdictionSize 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.
Source	ICS 209
Requirements Supported	Situation-Summary-Information

4.10 Glossary / List of Acronyms

NOTE: Glossary definitions contained herein are not intended to supersede existing definitions by any other organization or agency. Rather, these glossary items are provided in context of defining the EDXL-SitRep draft messaging standard - solely in order to clarify requirements statements.

TERM OR ACRONYM DEFINITION

ACH Automated Clearing House

Ack Acknowledgment

CAD Computer Aided Dispatch

CAP Common Alerting Protocol

CBRNE Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or attack

CDC Center For Disease Control

CIQ Customer Information Quality (a “contact information” standard)

Complex Incident A “complex” incident refers to “a series of situations or events that result in one incident” (Source: NIMS). Put another way, a complex incident may consist of one or more independently identified events and/or situations and/or incidents that require tracking and information exchange both as individual occurrences and combined for the overall incident”.

Constraint Schema A constraint schema is simply a subset of the standard reference schema which conforms to all the requirements and business rules of the reference schema. For example, an implementation of the SitRep standard may eliminate selected optional elements, or enhance the definition of a required element.

CSTE Council of State and Territorial Epidemiologists

DE Distribution Element

DHS Department of Homeland Security

DOT Department of Transportation

EDXL Emergency Data eXchange Language -

EDXL-DE Emergency Data eXchange Language - Distribution Element

EDXL-HAVE Emergency Data eXchange Language - Hospital aVailability Exchange

EDXL-RM Emergency Data eXchange Language - Resource Messaging

EIC Emergency Interoperability Consortium

Element “Elements” are logical groupings of message elements or “tags” for purposes of defining message structure

EMT Emergency Medical Technician

ERM Element Reference Model

ESF Emergency Support Functions

ETA Estimated Time of Arrival

Event For purposes of this messaging standard, “Situations”, “Incidents” and “Events” will be referred to generally as “incidents”. Situations in this context refer to occurrences of various scales - a collection of happenings, observations and actions that have been correlated on some basis that may require resources to perform Public Safety/Emergency/Disaster mitigation, planning and preparation, response or recovery.

It is a generic term referring to occurrences of any scale that may require some form of Emergency Response and Management, and that requires tracking and information exchange. An Event is a planned situation (e.g. a parade in Washington DC). “Event” is also used to refer to a situation that has not been formally identified as an incident. Like an incident, may be assigned an official ID, name or other descriptive attributes. EDXL-SitRep may refer to any situation whether an incident, event or other occurance.

FEMA Federal Emergency Management Agency

HazMat Hazardous Materials

HITSP Health Information Technology Standards Panel

HTTP Hypertext Transfer Protocol

ICS Incident Command System

ID Identification

IEEE Institute of Electrical and Electronics Engineers

IEPD Information Exchange Package Development

Incident For purposes of this messaging standard, “Situations”, “Incidents” and “Events” will be referred to generally as “incidents”. Situations in this context refer to occurrences of various scales - a collection of happenings, observations and actions that have been correlated on some basis that may require resources to perform Public Safety/Emergency/Disaster mitigation, planning and preparation, response or recovery.

A Situation can be an incident, an event, or any observable or predictable occurrence. It is a generic term referring to occurrences of any scale that may require some form of Emergency Response and Management, and that requires tracking and information exchange.

“Incident” is viewed from the NIMS Emergency Management perspective as a formal or informal declaration of emergency or disaster by an organization at the state, local, federal level or by a jurisdiction. An incident may be assigned an official ID, name or other descriptive attributes. EDXL-SitRep may refer to any situation whether an incident, event or other situation or occurance.

Jurisdiction In context of emergency response to incidents, “jurisdiction” has two similar definitions:

1. Reference to a geo-political area or location. A jurisdiction is pre-defined physical location or area over which legal authority extends. 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.

2. Reference to an organization or agency that has “Authority” over something (such as an incident, or a set of identified resources). Jurisdiction in this sence 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”.

MACS Multi-Agency Coordination System

MC Mobile Command

MEMA Maryland Emergency Management Agency

NCR DEH National Capital Region Data Exchange Hub

NFES National Fire Equipment System

NIEM National Information Exchange Model

NIMS National Information Management System

OASIS Organization for the Advancement of Structured Information Standards

OIC Office for Interoperability and Compatability

Profile (Taken from the OGC)

(Note: Considerable confusion exists in discussion and definition of the concept of a “profile”. The following definition was submitted by the OGC; however reference within this document more closely conforms to the term “constraint schema”.)

A profile of GML can be defined to enhance interoperability and to curtail ambiguity by allowing only a specific subset of GML. Application schemas can then conform to such a profile in order to take advantage of any interoperability or performance advantages that it offers in comparison with a complete GML. Such profiles can be defined for application schemas that are included in other OGC specifications. There are cases where reduced functionality is acceptable, or where processing requirements compel use of a logical subset of GML. For example, applications that do not need to handle XLink attributes in any form can adhere to a specific profile that excludes them; the constraint in this case would be to not use links. Other cases might include defining constraints on the level of nesting allowed inside tags (i.e. tree depth), or only allowing features with homogeneous properties as members of a feature collection. In many cases, such constraints can be enforced via new schemas; others may be enforced through procedural agreements within an information community.

PSG Practitioner Steering Group

RM Resource Messaging

S&T Science and Technology Directorate of DHS

SAFECOM SAFECOM is a communications program within the Office for Interoperability and Compatibility (OIC) that provides research, development, testing and evaluation, guidance, tools, and templates on communications-related issues to local, tribal, state, and Federal emergency response agencies working to improve emergency response through more effective and efficient interoperable wireless communications.

SitRep Situation Report

Situation For purposes of this messaging standard, “Situations”, “Incidents” and “Events” will be referred to generally as “incidents”. Situations in this context refer to occurrences of various scales - a collection of happenings, observations and actions that have been correlated on some basis that may require resources to perform Public Safety/Emergency/Disaster mitigation, planning and preparation, response or recovery.

SOAP Simple Object Access Protocol

SWG Standards Working Group -

UCUM Unified Code for Units of Measure

UOM Units of Measure

URN Uniform Resource Name

UTC Coordinated Universal Time

WHO World Health Organization

WMD Weapons of Mass Destruction

XML eXtensible Markup Language

5 Conformance

The EDXL-SitRep v1.0 specification has been written with the objective of making conformance to its requirements straightforward and unambiguous.

5.1 Conformance Targets

The 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 standard. 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 of consuming 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.3.2 to 3.3.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 Message

An 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 performed 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 requirements 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 Producer

A 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 SituationInformation 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 SituationInformation 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 message 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 A. Acknowledgements

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Rex Brooks, Network Centric Operations Industry Consortium (NCOIC)

Tim Grapes, Evolution Technologies, Inc., DHS Science and Technology Directorate, Office of Interoperability and Compatibility

Werner Joerg, IEM

Tom Ferrentino, Individual

Gary Ham, Individual

Don McGarry, MITRE Corporation

Rob Torchon, Individual

Appendix B. EDXL-SituationReporting XML Schema

The 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"?>

<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" 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:ct:1.0" schemaLocation="./EDXLSitRepDefaults-v1.0-wd18.xsd"/>

<xs:import namespace="urn:oasis:names:tc:emergency:edxl:gsf:1.0" schemaLocation="./edxl-gsf.v1.0.xsd"/>

<xs:complexType name="IReport" abstract="true"/>

<xs:complexType name="DisasterInformation">

<xs:sequence>

<xs:element name="DisasterName" type="xs:string" minOccurs="1" maxOccurs="1"/>

<xs:element name="DisasterDeclarationAuthority" type="xs:string" minOccurs="1" maxOccurs="1"/>

<xs:element name="DisasterDeclarationDateTime" type="ct:EDXLDateTimeType" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="StagingArea">

<xs:sequence>

<xs:element name="IncidentStagingArea" type="xs:string" minOccurs="1" maxOccurs="1"/>

<xs:element name="IncidentStagingAreaLocation" type="ct:EDXLLocationType" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="ResponseResourceTotals">

<xs:sequence>

<xs:element name="BranchDivisionGroup" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="Resource" type="ResourceCount" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="ResourceStatusType">

<xs:sequence>

<xs:element name="InventoryRefreshDateTime" type="ct:EDXLDateTimeType" minOccurs="1" maxOccurs="1"/>

<xs:choice>

<xs:element name="DeploymentStatus" type="ct:ValueListType" minOccurs="0" maxOccurs="1"/>

<xs:element name="DeploymentStatusDefault" type="ct:DeploymentStatusDefaultType" minOccurs="0" maxOccurs="1"/>

</xs:choice>

<xs:element name="Availability" type="xs:string"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="ResourceCount">

<xs:sequence>

<xs:element name="AgencyOrganization" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ResourceName" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ResourceTypeCategoryKind" type="ct:ValueListType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResourceDetail" type="ResponseResourcesDetail" minOccurs="0" maxOccurs="1"/>

<xs:element name="IsSufficient" type="xs:boolean" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="ResponseResourcesDetail">

<xs:sequence>

<xs:element name="ResourcePersonnelCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="UnassignedResourcePersonnel" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResourceRequiredCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResourceCommittedCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResourceOnHandCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResourceStillNeededCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResourceRequestedCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="DateTimeOrdered" type="ct:EDXLDateTimeType" minOccurs="0" maxOccurs="1"/>

<xs:element name="RequestedArrival" type="ct:EDXLDateTimeType" minOccurs="0" maxOccurs="1"/>

<xs:element name="EstimatedArrival" type="ct:EDXLDateTimeType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ReportToLocation" type="ct:EDXLLocationType" minOccurs="0" maxOccurs="1"/>

<xs:element name="OverheadPosition" type="ct:ValueKeyIntPairType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="WorkAssignment" type="ct:EDXLStringType" minOccurs="0" maxOccurs="1"/>

<xs:element name="SpecialInstructions" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="SpecialEquipmentAndSupplies" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="AdditionalAssistingOrganizations" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResourceStatus" type="ResourceStatusType" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="CommandOrganization">

<xs:sequence>

<xs:element name="CommandStructure" type="ct:EDXLStringType" minOccurs="0" maxOccurs="1"/>

<xs:element name="PositionTitle" type="PositionType" minOccurs="0" maxOccurs="1"/>

<xs:element name="PersonName" type="ct:PersonDetailsType" minOccurs="0" maxOccurs="1"/>

<xs:element name="Branch" type="ct:ValueKeyType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ReportsToPositionTitle" type="PositionType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ReportsToPersonName" type="ct:PersonDetailsType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ReportsToAgency" type="ct:ValueListType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="ReportsToBranch" type="ct:ValueKeyType" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="CasualtyAndIllnessCategory">

<xs:sequence>

<xs:element name="CasualtyAndIllnessCountCategory" type="CasualtyAndIllnessCountCategoryType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ResponderSummaryCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="NonResponderSummaryCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="ResponderSummaryCountToDate" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="NonResponderSummaryCountToDate" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="ReceivedMassImmunizations" minOccurs="0" maxOccurs="1">

<xs:complexType>

<xs:sequence>

<xs:element name="HaveReceivedMassImmunizationsCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="Remarks" type="ct:RemarksType" minOccurs="0"/>

<xs:element name="Estimate" type="ct:EstimateType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="RequireMassImmunizations" minOccurs="0" maxOccurs="1">

<xs:complexType>

<xs:sequence>

<xs:element name="RequireMassImmunizationsCount" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="Remarks" type="ct:RemarksType" minOccurs="0"/>

<xs:element name="Estimate" type="ct:EstimateType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="ShelterCountEstimate" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="NotifiableDiseaseNumbers">

<xs:sequence>

<xs:element name="DiseaseSuspected" type="ct:ValueKeyType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ProbableCause" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="CountOfSuspectedCases" type="xs:unsignedInt" minOccurs="1" maxOccurs="1"/>

<xs:element name="CountOfConfirmedCases" type="xs:unsignedInt" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="DebrisManagementType">

<xs:sequence>

<xs:element name="TotalDebrisGeneratedCY" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="DebrisClearedToDateCY" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="DebrisNotYetClearedCY" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="DaysToClearanceComplete" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="PercentOfJurisdictionWithDebrisImpacts" type="ct:PercentageType" minOccurs="0" maxOccurs="1"/>

<xs:element name="AreasWithDebrisImpacts" type="ct:ValueListType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="AreasWhereWorkNotStarted" type="ct:ValueListType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="DebrisDisposedToDateCY" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="DebrisNotYetDisposedCY" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="DebrisStorageSitesPercentFilled" type="ct:PercentageType" minOccurs="0" maxOccurs="1"/>

<xs:element name="DaysToDisposalComplete" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="ExternalAffairsType">

<xs:sequence>

<xs:element name="EffectivePublicCommunication" type="xs:boolean" minOccurs="0" maxOccurs="1"/>

<xs:element name="TalkingPoints">

<xs:complexType>

<xs:sequence>

<xs:element name="TalkingPoint" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Rumors">

<xs:complexType>

<xs:sequence>

<xs:element name="Rumor" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="SituationSummary">

<xs:sequence>

<xs:element name="IncidentCause" type="xs:string" minOccurs="1" maxOccurs="1"/>

<xs:element name="SignificantEvents" type="SignificantEventsType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="DamageAssessmentInformation" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="PrimaryHazards" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="HazMatIncidentReport">

<xs:complexType>

<xs:sequence>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="ExtentOfContamination" type="ct:EDXLLocationType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="GeneralPopulationStatus" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="ExternalAffairs" type="ExternalAffairsType" minOccurs="0" maxOccurs="1"/>

<xs:element name="HumanLifeAndSafetyThreat" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="LifeAndSafetyThreat" type="LifeAndSafetyThreatType" minOccurs="1" maxOccurs="unbounded"/>

<xs:element name="IncidentThreatSummaryAndRisk" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="FollowOnIndication" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="InfrastructureAffected" type="InfrastructureAffectedType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="DebrisManagement" type="DebrisManagementType" minOccurs="0" maxOccurs="1"/>

<xs:element name="PropertyDamage" type="PropertyDamageType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="PercentContained" type="ct:PercentageType" minOccurs="0" maxOccurs="1"/>

<xs:element name="RequestsForAdditionalSupport" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="TerrorismNexus" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="WeatherEffects" type="ct:WeatherInfoType" minOccurs="0" maxOccurs="1"/>

<xs:element name="WMDEffects" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="TransportationSystems" type="ct:ValueKeyStringPairType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="IncidentDecisionSupportInformation">

<xs:sequence>

<xs:element name="ProjectedIncidentActivity" type="ct:ValueKeyStringPairType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ProjectedNumberToBeSheltered" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>

<xs:element name="CriticalResourceNeeds" type="ct:ValueKeyStringPairType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="ProjectedFinalIncidentSize" type="xs:unsignedLong" minOccurs="0" maxOccurs="1"/>

<xs:element name="AnticipatedCompletion">

<xs:complexType>

<xs:sequence>

<xs:element name="AnticipatedCompletionDate" type="ct:EDXLDateTimeType" minOccurs="0" maxOccurs="1"/>

<xs:element name="Remarks" type="ct:RemarksType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="ProjectedDemobilization">

<xs:complexType>

<xs:sequence>

<xs:element name="ProjectedDemobilizationStartDate" type="ct:EDXLDateTimeType" minOccurs="0" maxOccurs="1"/>

<xs:element name="Remarks" type="ct:RemarksType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="EstimatedCosts">

<xs:complexType>

<xs:sequence>

<xs:element name="EstimatedCostsToDate" type="ct:CurrencyType" minOccurs="0" maxOccurs="1"/>

<xs:element name="Estimate" type="ct:EstimateType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="ProjectedCosts">

<xs:complexType>

<xs:sequence>

<xs:element name="ProjectedFinalCosts" type="ct:CurrencyType" minOccurs="0" maxOccurs="1"/>

<xs:element name="Remarks" type="ct:RemarksType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="EmergencyResponseIssues" type="EmergencyResponseIssuesType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="StrategicDiscussion" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="PlannedActions" type="xs:string" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="ReportVersionType">

<xs:choice>

<xs:element name="Version" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="VersionDefault" type="ct:ReportVersionDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="IncidentLifecycleType">

<xs:choice>

<xs:element name="IncidentLifecycle" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="IncidentLifecycleDefault" type="ct:IncidentLifecycleDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="ConfidenceType">

<xs:choice>

<xs:element name="Confidence" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ConfidenceDefault" type="ct:ConfidenceDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="UrgencyType">

<xs:choice>

<xs:element name="Urgency" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="UrgencyDefault" type="ct:UrgencyDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="SeverityType">

<xs:choice>

<xs:element name="Severity" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="SeverityDefault" type="ct:SeverityDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="ImmediateNeedsCategoryType">

<xs:choice>

<xs:element name="ImmediateNeedsCategory" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ImmediateNeedsCategoryDefault" type="ct:ImmediateNeedsDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="IncidentInfoType">

<xs:sequence>

<xs:element name="IncidentName" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>

<xs:element name="IncidentType" type="IncidentTypeType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="IncidentComplexity" type="ComplexityType" minOccurs="0" maxOccurs="1"/>

<xs:element name="IncidentStartDateTime" type="ct:EDXLDateTimeType" minOccurs="0" maxOccurs="1"/>

<xs:element name="GeographicSize">

<xs:complexType>

<xs:sequence>

<xs:element name="IncidentGeographicSize" type="xs:unsignedLong" minOccurs="0" maxOccurs="1"/>

<xs:element name="Estimate" type="ct:EstimateType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="DisasterInformation" type="DisasterInformation" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="IncidentLocation" type="ct:EDXLLocationType" minOccurs="1" maxOccurs="1"/>

<xs:element name="JurisdictionInformation" type="Jurisdiction" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="IncidentStaging" type="StagingArea" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="IncidentTypeType">

<xs:choice>

<xs:element name="IncidentType" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="IncidentTypeDefault" type="ct:IncidentTypeDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="PositionType">

<xs:choice>

<xs:element name="Position" type="ct:ValueKeyStringPairType" minOccurs="1" maxOccurs="1"/>

<xs:element name="PositionDefault" type="ct:PositionDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="CasualtyAndIllnessCountCategoryType">

<xs:choice>

<xs:sequence>

<xs:element name="CountCategory" type="ct:ValueKeyType" minOccurs="1" maxOccurs="1"/>

<xs:element name="Remarks" type="ct:RemarksType" minOccurs="0"/>

<xs:element name="Estimate" type="ct:EstimateType" minOccurs="0"/>

</xs:sequence>

<xs:sequence>

<xs:element name="CountCategoryDefault" type="ct:CasualtyAndIllnessCountCategoryDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:choice>

</xs:complexType>

<xs:complexType name="SignificantEventsType">

<xs:choice>

<xs:element name="SignificantEvents" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="SignificantEventsDefault" type="ct:SignificantEventsDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="LifeAndSafetyThreatType">

<xs:choice>

<xs:element name="LifeAndSafetyThreat" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="LifeAndSafetyThreatDefault" type="ct:LifeAndSafetyThreatDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="InfrastructureAffectedType">

<xs:choice>

<xs:element name="InfrastructureAffected" type="ct:ValueKeyStringPairType" minOccurs="1" maxOccurs="1"/>

<xs:element name="InfrastructureAffectedDefault" type="ct:InfrastructureAffectedDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="PropertyDamageType">

<xs:choice>

<xs:element name="PropertyDamage" type="ct:ValueKeyIntPairType" minOccurs="1" maxOccurs="1"/>

<xs:element name="PropertyDamageDefault" type="ct:PropertyDamageDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="EmergencyResponseIssuesType">

<xs:choice>

<xs:element name="EmergencyResponseIssues" type="ct:ValueKeyStringPairType" minOccurs="1" maxOccurs="1"/>

<xs:element name="EmergencyResponseIssuesDefault" type="ct:EmergencyResponseIssuesDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="ComplexityType">

<xs:choice>

<xs:element name="Complexity" type="ct:ValueListType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ComplexityDefault" type="ct:ComplexityDefaultType" minOccurs="1" maxOccurs="1"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="Jurisdiction">

<xs:sequence>

<xs:element name="Name" type="xs:string" minOccurs="1" maxOccurs="1"/>

<xs:element name="JurisdictionSize">

<xs:complexType>

<xs:sequence>

<xs:element name="GeographicSize" type="xs:unsignedLong" minOccurs="1" maxOccurs="1"/>

<xs:element name="Estimate" type="ct:EstimateType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Location" type="ct:EDXLLocationType" minOccurs="1" maxOccurs="1"/>

<xs:element name="Description" type="xs:string" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:element name="SitRep" type="SitRep"/>

<xs:complexType name="SitRep">

<xs:sequence>

<xs:element name="MessageID" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="PreparedBy" type="ct:PersonTimePairType" minOccurs="1" maxOccurs="1"/>

<xs:element name="AuthorizedBy" type="ct:PersonTimePairType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ReportPurpose" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ReportNumber" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ReportVersion" type="ReportVersionType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ForTimePeriod" type="ct:TimePeriodType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ReportTitle" type="ct:EDXLStringType" minOccurs="0" maxOccurs="1"/>

<xs:element name="IncidentID" type="ct:EDXLStringType" minOccurs="1" maxOccurs="unbounded"/>

<xs:element name="IncidentLifecyclePhase" type="IncidentLifecycleType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="OriginatingMessageID" type="ct:EDXLStringType" minOccurs="0" maxOccurs="1"/>

<xs:element name="PrecedingMessageID" type="ct:EDXLStringType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="Urgency" type="UrgencyType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ReportConfidence" type="ConfidenceType" minOccurs="1" maxOccurs="1"/>

<xs:element name="Severity" type="SeverityType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ReportingLocation" type="ct:EDXLLocationType" minOccurs="0" maxOccurs="1"/>

<xs:element name="ActionPlan" type="ct:EDXLStringType" minOccurs="0" maxOccurs="1"/>

<xs:element name="NextContact" type="ct:EDXLDateTimeType" minOccurs="0" maxOccurs="1"/>

<xs:element name="Report" type="IReport" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:element name="ManagementReportingSummary" type="ManagementReportingSummary"/>

<xs:element name="ResponseResourcesTotals" type="ResponseResourcesTotals"/>

<xs:element name="FieldObservation" type="FieldObservation"/>

<xs:element name="SituationInformation" type="SituationInformation"/>

<xs:element name="CasualtyAndIllnessSummary" type="CasualtyAndIllnessSummary"/>

<xs:complexType name="FieldObservation">

<xs:complexContent>

<xs:extension base="IReport">

<xs:sequence>

<xs:element name="ObservationLocation" type="ct:EDXLLocationType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ImmediateNeeds" type="ct:EDXLStringType" minOccurs="1" maxOccurs="1"/>

<xs:element name="ImmediateNeedsCategory" type="ImmediateNeedsCategoryType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="ObservationText" type="xs:string" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="SituationInformation">

<xs:complexContent>

<xs:extension base="IReport">

<xs:sequence>

<xs:element name="PrimaryIncidentInformation" type="IncidentInfoType" minOccurs="0" maxOccurs="1"/>

<xs:element name="SubIncidentInformation" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="SubIncident" type="IncidentInfoType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="ResponseResourcesTotals">

<xs:complexContent>

<xs:extension base="IReport">

<xs:sequence>

<xs:element name="ResourceTotal" type="ResponseResourceTotals" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="OrganizationAndAssignments" type="CommandOrganization" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="CasualtyAndIllnessSummary">

<xs:complexContent>

<xs:extension base="IReport">

<xs:sequence>

<xs:element name="SummaryCount" type="CasualtyAndIllnessCategory" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="NotifiableDiseaseNumbers" type="NotifiableDiseaseNumbers" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="ManagementReportingSummary">

<xs:complexContent>

<xs:extension base="IReport">

<xs:sequence>

<xs:element name="SituationSummary" type="SituationSummary" minOccurs="0" maxOccurs="1"/>

<xs:element name="DecisionSupportInformation" type="IncidentDecisionSupportInformation" minOccurs="0" maxOccurs="1"/>

<xs:element name="JurisdictionInformation" type="Jurisdiction" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:schema>

Appendix C. Time Elements (Constraints Apply to All Time Elements)

Element		ForTimePeriod
Type		ct:TimePeriodType
Usage		REQUIRED
Definition		The combination of the FromDateTime and the ToDateTime represents the ForTimePeriod addressed by this SitRep ReportNumber and Version (for which this report applies). This period should include all of the time since the last SitRep “ReportNumber”/”ReportVersion” was submitted, or if it is the initial SitRep IReport “ReportType”(Originating message), it should cover the time lapsed since the incident or event started. The time period may include one operational period, but may also include greater than an Operational Period based on agency/organizational reporting requirements. All elements of information contained in the SitRep IReport “ReportType” always apply only to the combination of the FromDateTime and the ToDateTime, equaling the ForTimePeriod.
Constraints	(1) The date and time SHALL be represented in the DateTime Data format (e.g., “2002-05-24T16:49:00-07:00” for 24 May 2002 at 16: 49 PDT). (2) Alphabetic timezone designators such as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00”. All [dateTime] elements SHALL be specified in the form "YYYY-MM-DDThh:mm:ssXzh:zm" where: YYYY indicates the year MM indicates the month DD indicates the day T indicates the symbol “T” marking the start of the required time section hh indicates the hour mm indicates the minute ss indicates the second X indicates either the symbol “+” if the preceding date and time are in a time zone ahead of UTC, or the symbol “-‘ if the preceding date and time are in a time zone behind UTC. If the time is in UTC, the symbol “-“ will be used. zh indicates the hours of offset from the preceding date and time to UTC, or “00” if the preceding time is in UTC zm indicates the minutes of offset from the preceding date and time to UTC, or “00” if the preceding time is in UTC Used in SitRep element / container
Source		ICS 203, 207, 209, 215
Requirements Supported		Report-DateTime-Information

Appendix D. Examples

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.

D.1 ICS209 Web Form Example

The 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/

Appendix E. Revision History

Revision	Date	Editor	Changes Made
edxl-sitrep-v1.0-wd08	23 Nov. 2010	Rex Brooks	First Full Working Draft
edxl-sitrep-v1.0-wd011	31 Dec. 2010	Rex Brooks	Major Revision Working Draft
edxl-sitrep-v1.0-wd015	10 Aug. 2011	Rex Brooks	Major Revision Working Draft
edxl-sitrep-v1.0-wd016	27 Sept. 2011	Rex Brooks	Major Revision Working Draft submitted for Emergency Management Technical Committee approval as Committee Specification Draft
edxl-sitrep-v1.0-wd18	24 April 2012	Rex Brooks	Major Revision Working Draft submitted for Emergency Management Technical Committee approval as Committee Specification Draft

	Number This Reporting Period			Total Number To Date
Casualty & Illness Summary Categories	Responder Summary Count	Non-Responder Summary Count	Total This Period	Responder Summary Count	Non-Responder Summary Count	Total to Date
NumberOfFatalities	1		1	1	2	3
NumberOfHospitalized			0	2	2	4
NumberOfWithInjury/Illness			0		6	6
NumberOfTrapped/In need of rescue			0			0
NumberOfMissing			0	2	2	4
NumberOfEvacuated			0			0
NumberOfSheltering In Place			0			0
NumberInTemporaryShelters			0			0
NumberInQuarantine			0			0
HaveReceivedMassImmunizationsCount			0			0
RequireMassImmunizationsCount			0			0
TOTAL	1	0	1	5	12	17	TotalNumberOfCasualtiesAffected
Responder Summary Percentage:	100.00%			29.41%
Non-Responder Summary Percentage:		0.00%			70.59%
Remarks: