All text is normative unless otherwise labeled.
The ongoing goal of the Emergency Data eXchange Language
(EDXL) project is to facilitate emergency information sharing and data exchange
across the local, state, tribal, national and non-governmental organizations of
different professions that provide emergency response and management services.
EDXL accomplishes this goal by focusing on the standardization of specific
messages (messaging interfaces) to facilitate emergency communication and
coordination particularly when more than one profession or governmental
jurisdiction is involved.
The current roster of EDXL Standards includes:
·
The Common Alerting Protocol v1.2 specification
(EDXL-CAP)
·
The Distribution Element specification v1.0 (EDXL-DE)
·
The Hospital AVailability Exchange specification
v1.0 (EDXL-HAVE)
·
The Resource Messaging specification v1.0 (EDXL-RM)
The primary purpose of the Emergency Data Exchange Language
Situation Reporting (EDXL-SitRep) Specification is to provide a set of standard
formats for XML emergency response messages specifically aimed at transmitting
timely situation reports. These situation reports are specifically designed as
payloads of the Emergency Data Exchange Language Distribution Element
(EDXL-DE). Together EDXL-DE and EDXL-SitRep are intended to expedite
well-informed incident command decisions needed to respond effectively and
adapt to emergency incidents, facilitating communication across various
responding organizations and up the chain of command. The Distribution Element
may be thought of as a container that provides the information to route
"payload" message sets (such as alerts, hospital availability
reports, resource messages or situation reports), by including key routing
information such as distribution type, geography, incident, and
sender/recipient IDs.
The EDXL-SitRep message is constrained to the set of
pre-defined Report types contained in this specification. The EDXL-SitRep
message is intended to be the payload or one of the payloads of the
Distribution Element which contains it.
Through a practitioner-driven approach, the Command, Control
and Interoperability Division (CID) within the U.S. Department of Homeland Security's
Science and Technology Directorate creates and deploys information resources to
enable seamless and secure interactions among state, local, tribal,
international, private entities, homeland security stakeholders and other
federal entities. CID creates and
deploys Information resources such as standards, frameworks, tools, and
technologies.
CID is organized into five program areas: Basic/Futures
Research; Cyber Security; Knowledge Management Tools; Office for
Interoperability and Compatibility (OIC); and Reconnaissance, Surveillance, and
Investigative Technologies.
Following voice interoperability programs such as SAFECOM,
the OIC’s interoperable messaging standards program was initiated as one of the
President’s e-Gov initiatives in 2001. The OIC mission is to serve as the
standards program within the Federal Government to facilitate local, tribal,
state, and federal public safety and emergency response agencies to improve
emergency / disaster response through effective and efficient interoperable
data sharing. OIC sponsors the process to facilitate practitioner requirements
for the development of EDXL standards.
EDXL will accomplish this mission through the
standardization of specific messages (XML messaging interfaces) which
facilitate coordination and emergency communication between disparate software
applications and systems - particularly when more than one profession or
jurisdiction is involved.
The EDXL program is an open, public practitioner-driven
process driven solely by cross-profession emergency practitioners through an
OIC-sponsored Practitioner Steering Group (PSG) and Standards Working Group
(SWG). The EDXL program is also a
public-private partnership working with the EIC (Emergency Interoperability
Consortium), Vendor communities, and OASIS (Organization for the Advancement of
Structured Information Standards), which develops and publishes the open,
public EDXL standards free of charge.
The OIC-sponsored Practitioner Steering Group (PSG)
governance was formalized following publication of the EDXL Distribution
Element. It plays a key role in the
direction, prioritization, definition, and execution of the DHS-OIC program.
The group is comprised of representatives of major emergency response associations
and organizations, setting priorities and providing recommendations regarding
messaging standards development as well as the other facets of the OIC-EDXL
program.
The PSG identified the EDXL Situation Reporting
(EDXL-SitRep) Specification effort as the top priority standard by this group
following the development of EDXL-DE, EDXL-HAVE and EDXL-RM. Utilizing standard process and governance,
the requirements and specification effort was initiated by this group in
partnership with industry members of the Emergency Interoperability Consortium
(EIC) and the Standards Working Group (SWG).
The EDXL-SitRep draft specification was developed based on explicitly
defined requirements which were submitted to the OASIS Emergency Management
Technical Committee (EM-TC) to begin work on this international EDXL-SitRep
standard.
Tthe EDXL Situation Reporting standard defines five (5)
separate and specific report types to support incident command decision-making
across the emergency incident life-cycle. This includes preparedness,
pre-staging of resources, initial, ongoing response, recovery and
demobilization / release of resources and after-action analysis to identify
needed improvements in ongoing preparedness.
1.3
Structure of the EDXL Situation Reporting
Specification [comment?]
The EDXL Situation Reporting standard document structure is
defined using successively more detailed or constrained artifacts in the form
of textual descriptions, diagrams, figures, tables and Appendices. The
EDXL-SitRep XML Schema is provided separately. The overall structure of the
EDXL Situation Report is first represented in an Element Reference Model (ERM).
The ERM is the foundation from which individual constraint schemas (individual
situation report types) are defined.
The structure of the EDXL Situation Reporting standard is
defined in the following sections:
·
Section 3.1, The Element
Reference Model (ERM), shows the abstract structural relationships of the main
components of the EDXL-SitRep.
·
Section 3.2, Distribution
of EDXL Situation Reporting, describes practitioner requirements which are met
through the EDXL-Distribution Element (DE)
·
Sections 3.4.2 through 3.4.6 define the five (5) individual EDXL-SitRep report
types
·
Section 4 The Data
Dictionary, defines each element contained in the EDXL-SitRep standard message
These sections together define the message structure,
message element definitions, optionality and cardinality.
The following descriptions provide a brief overview of each
EDXL-SitRep component to assist with an overall understanding of this
standard's diagrams, figures and tables.
The Non-normative Element Reference Model diagram in Figure
2 of Section 3.1 shows the abstract structural
relationships of the main components shown as packages of specific message
elements. The EDXLSitRepRoot ERM diagram in Figure 3 of Section
3.3.1 shows the structural relationships of the main Situation Report
elements used throughout the individual situation reports.
1.
The EDXLSitRepRoot element of the EDXL-SitRep
message, containing elements used throughout each individual situation report
such as IReport, MessageID, PreparedBy, and IncidentID.
2.
A SituationInformation report type identifies
and describes the incident with message elements such as IncidentName,
IncidentLocation and IncidentType.
3.
A FieldObservation report type provides a fast
and flexible basic report of an observation in the field by emergency response
& management professionals, as a textual description by human parties
acting as mobile sensors. This report type is intended for standardized receipt
of Field Observations, which may then undergo verification and/or integration
into formal Situation Reporting.
4.
A CasualtyAndIllnessSummary report type provides
counts by responders and non-responders for various categories such as
fatalities, missing and hospitalized over specified time periods. These data items may be collected as needed and
combined in the manner required for specific reports or for decision making
purposes.
5.
A ResponseResourcesTotals report type contains
responding resources and resource needs to manage and coordinate resource
decisions. This report type keeps this
information organized together for ease of reference and reuses the EDXL
Resource Messaging Elements as needed.
6.
A ManagementReportingSummary report type
provides for the collection of data related to management concerns such as
operational planning, damage and threat assessment, weather conditions, etc. It
contains incident organization information where cross-profession or
jurisdiction Incident Command structure is in place.
6.1.
A SituationSummary package provides supporting
information for ManagementReportingSummary or user-defined custom reports.
6.2.
A DecisionSupportInformation package likewise
provides detailed information supporting the ManagementReportingSummary report
type or user-defined custom reports.
7.
A Supporting Elements Model package provides the
following:
7.1.
A CommonTypes Package of elements organized
separately to be reused as needed, including. a ValueListTypeInformation
subset.
7.2.
A ContactInformation Package of elements
organized separately to be reused as needed, including the EDXL-CIQ Profile;
7.3.
A LocationInformation Package of elements
organized separately to be reused as needed including the EDXL-GSF Profile.
Table 1 in Section 3.3 provides a
Situation Report Type Summary of the five (5) specific types of Situation
Report messages. This provides a quick overview of the message types contained
in this standard.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in
this document are to be interpreted as described in [RFC2119].
The term “Conditional” as used in this
specification is to be interpreted that a message element MUST be
used, according to specified rules, within a particular report message type
(elements MUST be one of “Required,” “Optional” or “Conditional”).
1.5 Normative References [comment?]
[EDXL-SitRep-Rqmts]
DHS
S&T-OIC, EDXL Requirements Statement
and draft Messaging Specification for the Situation Reporting Messaging
Standard (EDXL-SitRep), Version 1.2 http://www.oasis-open.org/committees/download.php/32036/EDXL-SitRep-Rqmts-MsgSpec020209.pdf 2 February 2009.
[RFC2119]
S. Bradner, Key
words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119,
March 1997. http://www.ietf.org/rfc/rfc2119.txt.
[RFC2046]
N. Freed, Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types, IETF RFC 2046, November 1996. http://www.ietf.org/rfc/rfc2046.txt.
[RFC3066]
H. Alvestrand, Tags for the Identification
of Languages, IETF RFC 3066, January 2001. http://www.ietf.org/rfc/rfc3066.txt.
[WGS 84]
National
Geospatial Intelligence Agency, Department of Defense, World Geodetic System
1984, NGA Technical Report TR8350.2, January 2000. http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf.
[XML 1.0]
T.
Bray, Extensible Markup Language (XML) 1.0 (Third
Edition), W3C REC-XML-20040204, (Fifth Edition), 26 November 2008. http://www.w3.org/TR/REC-xml/.
[namespaces]
T.
Bray, Namespaces in XML, W3C REC-xml-names-19990114, (Third Edition) W3C
Recommendation 8 December 2009. http://www.w3.org/TR/REC-xml-names/.
[dateTime]
N. Freed,
XML Schema Part 2: Datatypes (Second Edition), W3C
REC-xmlschema-2, October 2004. http://www.w3.org/TR/xmlschema-2/#dateTime.
[EDXL-SitRep-Rqmts]
Emergency
Data Exchange Language (EDXL) Requirements Statement and draft Messaging Specification for the Situation
Reporting Messaging Standard (EDXL-SitRep) Version1.2, Prepared by the DHS S&T-OIC EDXL
Messaging Standards Project Team, 2 February 2009. http://www.oasis-open.org/committees/download.php/32036/EDXL-SitRep-Rqmts-MsgSpec020209.pdf.
[EDXL-DE]
Emergency
Data Exchange Language (EDXL) Distribution Element Version 2.0, Edited by
Jeff Waters, 19 Sept. 2013, Committee
Specification CS02. Latest version: http://docs.oasis-open.org/emergency/edxl-de/v2.0/edxl-de-v2.0.html.
[EDXL-HAVE]
Emergency
Data Exchange Language (EDXL) Hospital AVailablity Exchange, Edited by
Sukumar Dwarkanath. 01 November 2008. OASIS Standard OS01. http://docs.oasis-open.org/emergency/edxl-have/os/emergency_edxl_have-1.0-spec-os.html. Latest version: http://docs.oasis-open.org/emergency/edxl-have/v1.0/emergency_edxl_have-1.0.html.
[EDXL-RM]
Emergency Data Exchange Language Resource
Messaging (EDXL-RM) 1.0.
Edited by Dr. Patti Aymond, Rex Brooks, Tim Grapes, Gary Ham, Dr. Renato
Iannella, Dr. Karen Robinson, Werner Joerg, and Alessandro Triglia. 1 November
2008. OASIS Standard OS 01. http://docs.oasis-open.org/emergency/edxl-rm/v1.0/os/EDXL-RM-v1.0-OS.html. Latest version: http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.html.
ISO
4217:2001, Codes for the representation of currencies and funds
2 Design Principles and Concepts
(Non-normative) [comment?]
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 [comment?]
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 [comment?]
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 [comment?]
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 [comment?]
Levee Break and
Evacuation with Law Enforcement Focus
The National
Weather Service is reporting that there is no let-up in sight to the rain storm
that has been drenching the area for the last 36 hours. An unprecedented amount of rain has
fallen. A levee next to a local town is
threatening to break.
Estimates of
engineers indicate that the levee will only hold for another 2 hours. This is the time frame in which the initial
response must take place. Emergency
Management has notified local law enforcement: that the 2,000 residents at risk
must be evacuated immediately. 200 are
elderly, of which 50 are non-ambulatory.
Rising water
levels also threaten to cause two major rivers, one flowing through a major
neighboring town to the west, to overflow their banks and cause massive
flooding across the region. These floods
will impact areas of the original town not affected by the impending levee
break.
If these rivers
do overflow their banks, then an additional and much larger number of people
will need to be warned and evacuated.
Full use case
available: http://www.oasis-open.org/committees/download.php/32042/EDXL_use_case_LeveeBreakEvac_v1.1final.doc.
This scenario
takes place in Bayport on a coastal island across a bridge from Fisherville on
the mainland. The nearest large city is
Central City which is 40 miles away and has two hospitals. The first, Faith Hospital, is a regional
cardiac catheterization and care center. Central City Hospital is a level 1
trauma center and operates a medevac helicopter service called Med Flight-1.
Fisherville has a small community hospital with a physician-staffed ER. Fisherville Hospital runs a health clinic in
Bayport, staffed by a physician assistant. The Bayport EMS (BEMS) staff
supports the physician assistant, as well as Central City and Faith Hospital
physicians who have patients in Bayport, by working in the clinic
Full use case
available: http://www.oasis-open.org/committees/download.php/32041/EDXL_use_case_EMS_Callv1.4final.doc.
2.2.4 Road Rescue -- Highway Incident Scenario
& Use Case [comment?]
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 [comment?]
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) [comment?]
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) [comment?]
This section
shows the EDXL–SitRep Element Reference Model (ERM). The purpose of the ERM is
to define the SitRep structure and the relationships between the main entities
and their elements. Using the Unified Modeling Language as a means to
illustrate the relationships, the ERM is not strictly normative. It is important that the ERM is not used as
an implementation model. The exact semantics and structure are captured in the
subsequent sections in the specific predefined EDXL Situation Report Message
Types.
The ERM is
organized into a top level views first and then in groups of related elements
with relationships between those groups and the report type in which they are
used.
The Supporting
Elements Model package is not specifically associated with any report type or
group of elements because these sets of elements are common to all EDXL
messages and may be used in any EDXL SitRep message to which they apply.
3.1.1
Report Types Instantiate Abstract Type IReport
(Non-normative) [comment?]
The
EDXLSituationReporting XML Schema is provided separately and included in Appendix B. The top level element (<SitRep> aka
<EDXLSitRepRoot>) contains the elements shown in Figure 1. In particular
it contains a report-type dependent element report (<report>) of type
<IReport>. <IReport> is an Abstract Type that serves as the basis for
the five different SitRep report types as shown in Figure 2.
<report xsi:type="FieldObservationType">
Where FieldObservationType references <IReport> as follows:
<xs:complexType
name="FieldObservationType">
<xs:complexContent>
<xs:extension base=”IReport”>
...
</xs:extension>
</xs:complexContent>
</xs:complexType>
Figure
1: SitRep TopLevel Structure
This is explained in more detail in the Data Dictionary Section.
Note: the code above declares the Report type based on <IReport> from
the XML Schema shown below:
<xs:complexType
name="IReport" abstract="true"
<xs:sequence>
<xs:element name=”extension”
type=”ext:ExtensionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
</xs:sequence>
/>
The EDXL Extensions Section elaborates on the “ext:ExtensionType” extension
mechanism of EDXL.
Figure 2: EDXL–SitRep Element Reference Model (ERM) – top level
The SitRep-ERM shows the element-level details for the main entities in
EDXL-SitRep overall. The semantics for each of the elements is defined in Sections 3.3.2 through 3.3.5.
3.2
Distribution of EDXL-SitRep [comment?]
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) [comment?]
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 [comment?]
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
Identifying Message Sender [comment?]
The Requirement for identifying the “Message
Sender” of the EDXL-SitRep is handled by one or two elements of EDXL-DE
v1.0.The EDXL-DE v1.0 <senderID> or an element with the identical
definition and properties MUST be present in the EDXL-DE or other routing
mechanism used to distribute an EDXL-SitRep message. The <senderRole> or
an element with the identical definition and properties MAY be present.
<senderRole> is expressed in an XML ValueList
and Value.
·
The list and associated
value(s) is in the form:
<senderRole>
<valueListUrn>valueListUrn</valueListUrn>
<value>value</value>
</senderRole>
·
Where the content of
<valueListUrn> is the Uniform Resource Name of a published list of values
and definitions, and the content of <value> is a string (which may
represent a number) denoting the value itself.
·
Multiple instances of the
<value>, MAY occur with a single <valueListUrn> within the
<senderRole> container.
3.2.1.3
DateTime Message Sent [comment?]
The EDXL-DE v1.0 <dateTimeSent> element is used
to established the date and time the EDXL-DE package containing the EDXL-SitRep
message is sent.
·
DateTime elements are
represented consistent with previous EDXL standards (24-hour clock):
·
The date and time is
represented in [DateTime] format (e. g., "2008-06-11T16:49:00-07:00"
for 11 June 2008 at 16:49 PDT).
·
Alphabetic time zone
designators such as “Z” MUST NOT be used. The time zone for UTC MUST be
represented as “-00:00” or “+00:00”
3.2.1.4
Identifying Situation Report
Type [comment?]
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’ [comment?]
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 [comment?]
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
[comment?]
A graphic representation for the
IncidentCommandStructure detailed in the SitRep may be optionally provided as
an aid to understanding the hierarchy of a given organization’s or agency’s
position roles. This should be provided in the form of a graphic image carried by
the EDXL-DE message header as separate content object.
A digital version of a signature may optionally be
included to provide the authority that authenticates a particular Situation
Report. A digital signature must be
provided in the form of a graphic image carried by the EDXL-DE message header
as separate content object.
3.2.1.9
Sensitivity
and Releasability [comment?]
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
Supporting Elements [comment?]
Several Element Types, such as incidentStartDateTime, borrow re-usable elements from the
EDXL Common Types that apply to and support multiple areas of the SitRep
messages. For instance incidentStartDateTime relies on the EDXL-CT for a common
date/time format.
The Supporting Elements Model
distinguishes three groups of elements: CommonTypes (EDXL-CT),
Contact Information (EDXL-CIQ) and
Location Information (EDXL-GSF). In this Specification, only the EDXL-CT
elements/types are being used directly; yet some elements in EDXL-CT depend on
EDXL-CIQ (e.g. ct:PersonDetailsType) or on EDXL-GSF (e.g. ct:EDXLLocationType).
The following elements are used in
this specification and can be found at the locations cited in the normative
references in Section 1.6 above.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ct:ValueKeyStringPairType
|
|
|
|
EDXL-CT (Top
Level Elements)
|
|
|
|
For a presentation
of difference between ValueListType and ValueKeyType, see Appendix
C.1: Selecting values from lists.
3.3.2 Community Extensions [comment?]
SitRep supports supplemental
inclusion of community-defined sets of name/value pairs, referred to here as
“Community Extensions” or simply “Extensions” for short. For example, if you
send a DE message with an alert or image about an earthquake, you might want to
include some specific earthquake data, like the magnitude and depth of the
earthquake. There are no earthquake-specific fields in the DE; however, your
community can extend the DE to include that information which you represent as
a set of parameter elements specifically designed to represent earthquake data.
The “Community Extensions” concept solves several major problems for improving
information sharing and developing standards for the emergency management
community. First, the nature of emergencies is that the unexpected will happen
and emergency managers need flexibility to send whatever information is needed.
Second, an emergency begins and often stays local, so local authorities and
users need control to send the information they decide is important to address
the current emergency. Third, communities need the opportunity to explore
potential new standards. The parameter name/value extension mechanism, along
with the registration and best practice guidance, provides an on-ramp for
communities to determine what works well for them. Those Community Extensions
which are most successful can be incorporated formally into future standards.
(For more detail see Appendix C.2: EDXL Extensions).
3.4
Situation Report Root and
Report Types [comment?]
As further described below, the EDXLSitRepRoot
element is the top level element of the EDXL-SitRep message, containing
elements used throughout each individual situation report. This section
describes the primary components of EDXL-SitRep including the Root element and
the five (5) Report Types.
The SitRep framework is based on a report model. In
this model messages do not expect a Response, although a situation report can
be requested. There is no inherent message exchange protocol represented in
this standard.
A SitRep message MUST be carried as the payload of
the EDXL-DE or any other distribution mechanism that satisfies the DE required
parameters: distribution type values of Report, Update, Cancel, Request,
Response, Ack and Error.
For example, the acknowledgement of a SitRep
message is handled by the distribution mechanism. When a message recipient
receives a SitRep message, it uses the EDXL-DE DistributionType value of “Ack”
as an acknowledgement. An acknowledgement is intended to inform the sender that
the SitRep message has been received.
EDXL-SitRep communication is characterized by two
classes of primary actors An “Incident Command” is an actor that needs or
requires a situation report to undertake response decision(s) during an
incident. An “Incident Command System” is an owner, or distributor, or manager
of situation reports that can meet the needs of Incident Command. These actors
need not belong to the same jurisdiction or organization.
EDXL-SitRep provides five (5) situation report
messages defined in this standard, which are summarized in Table 1 below.
Table 1: Situation Report Message Type Summary--
informative only. It shows how situation reports might flow in incident command
|
|
|
|
|
|
Basic report that
describes an observation that is directly observed by the reporter (an
emergency professional).
|
On-Scene Incident
Command / Planning Section / Situation Unit
|
|
|
Message used to provide
information on responding resources and resource needs to manage and
coordinate resource decisions.
|
On-Scene Incident
Command / Planning Section / Situation Unit
|
ResponseResourcesTotalsType
|
Message used to provide
information on responding resources and resource needs to manage and
coordinate resources.
|
On-Scene Incident
Command / Logistics Section
|
CasualtyAndIllnessSummaryType
|
Message used to
summarize information pertaining to the number and status of categorized
casualties and victims of infectious agents associated with the incident.
|
Incident Command System/
Logistics Section / Services Unit / Medical Services
|
ManagementReportingSummaryType
|
Message used to
summarize information and data relevant to ongoing management of incident
response, typically used within the Incident Command Chain or across such
chains between jurisdictions.
|
Incident Command System
/ PIO / Logistics Section / Communications
|
Table 2 (below) summarizes all the Message Types
and their element contents, Including the Situation Report Root elements that
can be used in any Message Type. The specific details on each of the Message
Types are outlined in the following sections.
Table 2: Message Element Lists
and Constraints
Table 2.1: Situation Report Root – applies to
all message types
Table
2.2: FieldObservation
Table 2.3:
SituationInformation
|
|
|
|
|
|
|
primaryIncidentInformation
|
|
|
|
|
|
primaryIncidentInformation / subIncidentInformation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IncidentInformationType.disasterInformation
|
|
|
|
disasterDeclarationAuthority
|
|
disasterDeclarationDateTime
|
|
Note: situationInformation structure is actually a choice:
{{{primaryIncidentInformation [1..1]} {subIncidentInformation [0..*]}} |
{subIncidentInformation [1..*]}} [1..1]
Table
2.4 ResponseResourcesTotals
|
|
|
|
|
|
|
|
|
|
organizationAndAssignments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
resourceTotal.resource.resourceDetail
|
|
|
|
unassignedResourcePersonnel
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
specialEquipmentAndSupplies
|
|
additionalAssistingOrganizations
|
|
|
|
|
|
resourceTotal.resource.resourceDetail.resourceStatus
|
|
|
|
|
|
|
|
organizationAndAssignments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: responseResourcesTotals structure is actually a
choice:
{{resourceTotal [1..1]} | {organizationAndAssignments[1..1]}
[1..*]
Table
2.5 CasualtyAndIllnessSummary
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
casualtyAndIllnessCountCategory
|
|
|
|
|
|
responderSummaryCountToDate
|
|
nonResponderSummaryCountToDate
|
|
receivedMassImmunizations
|
|
|
|
|
|
|
|
|
SummaryCount.casualtyAndIllnessCountCategory
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: casualtyAndIllnessSummary structure is actually a
choice:
{{summaryCount [1..1] | {notifiableDiseaseNumbers [1..1]}}
[1..*]
Table
2.6 ManagementReportingSummary
|
|
|
|
|
|
|
|
|
|
decisionSupportInformation
|
|
|
|
|
|
|
|
|
|
|
damageAssessmentInformation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
incidentThreatSummaryAndRisk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
requestsForAdditionalSupport
|
|
|
|
|
|
|
|
|
|
|
situationSummary.externalAffairs
|
effectivePublicCommunication
|
|
|
|
|
|
situationSummary.debrisManagement
|
|
|
|
|
|
|
|
|
|
|
percentOfJurisdictionWithDebrisImpacts
|
|
|
|
|
|
|
|
|
|
|
debrisStorageSitesPercentFilled
|
|
|
|
|
|
situationSummary.propertyDamage
|
|
|
|
|
|
|
|
decisionSupportInformation
|
projectedIncidentActivity
|
|
projectedNumberToBeSheltered
|
|
|
|
projectedFinalIncidentSize
|
|
anticipatedCompletionDate
|
|
projectedDemobilizationStartDate
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: managementReportingSummary structure is actually a
choice:
{{{situationSummary [1..1]} {decisionSupportInformation
[0..1]} {jurisdictionInformation [0..*]}} |
{{decisionSupportInformation
[1..1]} {jurisdictionInformation [0..*]}} | {jurisdictionInformation [1..*}}
3.4.1 EDXLSitRep Root
Elements [comment?]
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.4.2 FieldObservation Report Type [comment?]
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.4.2.2
Field
Observation Element Reference Model (Non-normative) [comment?]
Figure 4 shows the FieldObservation report type Element
Reference Model. The ERM shows the element-level details for the main entities
in this fundamental report message type.
The schema for a FieldObservation message is supplied
separately at http://docs.oasis-open.org/emergency/edxl-sr/v1.0/os/ and can be
found in Appendix B.
Figure 4: EDXLSitRep
ERM for FieldObservation Report Type
3.4.3 SituationInformation
Report Type [comment?]
The “SituationInformation” report message type details the
incident to which the current response is being mounted with elements such as
incidentName, incidentKind, incidentComplexity and affectedJurisdiction.
SituationInformation intends to draw a concise and accurate picture of the
situation.
3.4.3.2
SituationInformation Element Reference Model [comment?]
Figure 5 below shows the SituationInformation report type
Element Reference Model. The ERM shows the element-level details for the main
entities in the SituationInformation report message type.
In addition, there are rules that apply to several elements
that should be reviewed in the Message Rules section.
Figure 5: EDXLSitRep ERM for SituationInformation
Message
The schema for a SituationInformation message is supplied
separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
3.4.4 ResponseResourcesTotals
Report Type [comment?]
The “ResponseResourcesTotals” report type is used to
organize and report on the Resources needed or on hand for responding to the
current incident.
3.4.4.2
ResponseResourcesTotals Element Reference Model [comment?]
Figure 6 shows the ResponseResourcesTotals report type
Element Reference Model. The ERM shows the element-level details for the main
entities in the ResponseResourcesTotals report message type.
The schema for a FieldObservation message is supplied
separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
Figure 6: EDXLSitRep ERM for
ResponseResourcesTotals Message
The schema for a ResponseResourcesTotals message is supplied
separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
3.4.5 CasualtyAndIllnessSummary
Report Type [comment?]
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.4.5.2
CasualtyAndIllnessSummary Element Reference
Model [comment?]
Figure 7 below shows the CasualtyAndIllnessSummary report
type Element Reference Model. The ERM shows the element-level details for the
main entities in the CasualtyAndIllnessSummary report message type.
Figure 7 EDXLSitRep ERM for
CasualtyAndIllnessSummary Message
The schema for a CasualtyAndIllnessSummary message is
supplied separately at
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in
Appendix B.
3.4.6 ManagementReportingSummary Report Type [comment?]
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.4.6.2
ManagementReportingSummary Element Reference
Model [comment?]
Figure 8 below shows the ManagementReportingSummary report
type Element Reference Model. The ERM shows the element-level details for the
main entities in the ManagementReportingSummary report message type.
The schema for a ManagementReportingSummary message is
supplied separately at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/os/ and can be found in Appendix B.
Figure 8: EDXLSitRep ERM
for ManagementReportingSummary
The data dictionary is intended to provide detailed
definition of each element contained in the EDXL-SitRep standard. Where discrepancies may exist between this
dictionary, the Element Reference Model (ERM), and the normative XML, the
normative XML shall take precedence.
·
Element – Name of the element.
·
Type – Type or format of the element.
·
Usage – Optionality and Cardinality.
·
If no optionality specified, then the element is
“Optional”.
·
If no Cardinality specified, the element ”MUST
be used once and only once”
·
Definition – Definition of the element.
·
Comments – Additional comments or
examples to add clarity.
·
Constraints – Limits imposed on the
element. Also notes the container or
“parent” to which the element belongs.
·
Source – Source of the requirement or
usage of the element.
·
Requirements Supported – A code
representing and referring to each requirement contained in the original
submission from the practitioner process to OASIS. EACH general, functional or
information requirement is accounted for by one or more elements in the data
dictionary, and/or by relationships in the message structure, one or more
business rules, or through the overall standard (e.g. for general and
functional requirements).
4.1
“Routing Header” Elements [comment?]
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.
|
|
|
|
|
|
|
|
|
|
|
Confidentiality and combinedConfidentiality
|
|
|
Confidentiality and combinedConfidentiality
|
|
|
“XMLcontent” and “nonXMLcontent” containers
|
|
|
|
|
|
“nonXMLcontent” containers
|
4.2
EDXL SitRep Top Level Elements [comment?]
The EDXL-SitRep message consists of a set of core data that
are common to all reports and a report specific element named <report> of
abstract type <IReport>. <IReport> can be instantiated by any one
of the five (5) separate additional data structures, each of which is needed to
build one of the five (5) specialized EDXL-SitReps. The schema is provided
separately and replicated in Appendix B.
|
|
|
|
|
|
|
|
Top level
element type of all situation reports
|
|
|
Holds elements common to all
report types and a report specific element <report>
|
|
|
Root element MUST
appear once and only once
|
|
|
|
|
|
·
messageID
[1..1]: ct:EDXLStringType
·
preparedBy
[1..1]: ct:PersonTimePairType
·
authorizedBy
[1..1]: ct:PersonTimePairType
·
reportPurpose
[1..1]: ct:EDXLStringType
·
reportNumber
[1..]: xs:unsignedInt
·
reportVersion
[1..1]: ReportVersionDefaultValues
·
forTimePeriod
[1..1]: ct:TimePeriodType
·
reportTitle
[0..1]: ct:EDXLStringType
·
incidentID
[1..*]: ct:EDXLStringType
·
incidentLifecyclePhase
[0..*]: IncidentLifecycleDefaultValues
·
originatingMessageID
[0..1]: ct:EDXLStringType
·
precedingMessageID
[0..*]: ct:EDXLStringType
·
urgency [0..1]:
UrgencyDefaultValues
·
reportConfidence
[1..1]: ConfidenceDefaultValues
·
severity [1..1]:
SeverityDefaultValues
·
reportingLocation
[0..1]: ct:EDXLLocationType
·
actionPlan
[0..1]: ct:EDXLStringType
·
nextContact
[0..1]: ct:EDXLDateTimeType
·
report [1..1]:
IReport
|
|
|
|
|
|
|
The <report> element in SitRepType is a placeholder
for report specific data. It is an abstract type that is instantiated by any
one of the five (5) separate additional data structures, each of which is
needed to build one of the five (5) specialized EDXL-SitReps.
<xs:complexType name="IReport"
abstract="true">
<xs:sequence>
<xs:element
name="extension" type="ext:ExtensionType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
This means that <IReport> is not directly used in an
instance document. It is instantiated by a report specific type that extends
the abstract type <IReport> and complements it with report specific, as
shown here:
<xs:element
name="Report" type="IReport" minOccurs="1"
maxOccurs="1"/>
Report can then be used to declare the Report Type of any
given EDXL-SitRep message as shown here:
<Report
xsi:type="FieldObservation">
|
|
|
|
|
|
|
|
Abstract
Type used to characterize an EDXL-SitRep message as one of five (5)
predefined kinds such as “FieldObservation”.
|
|
|
See
section 3.1.1 for diagrammatic representation of the relationship
between IReport and Report.
|
|
|
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.
|
|
|
|
|
|
Extension [0..*]:
ext:ExtensionType
|
|
|
|
|
|
|
The five (5) distinct “Reports”, defined in Sections 3.4.2 through 3.4.5, provide a
method to componentize the overall EDXL-SitRep standard into logical groups of
elements that support a common purpose.
For example, the ’Casualty and Illness Summary’ is focused
only on rollup or aggregation of numbers and percentages representing human
casualties by categories such as fatalities, hospitalized or missing.
4.2.2 Common SitRep
Elements [comment?]
<sitRep> is the top level element of any sitRep
message. It contains a set of shared message elements used across the five (5)
predefined EDXL-SitRep “Reports”, that convey information such as MessageID,
PreparedBy and ForTimePeriod.
|
|
|
|
|
|
|
|
|
|
|
Each
EDXL-SitRep contains an identifier that uniquely identifies the EDXL-SitRep
message / Report.
|
|
|
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.
|
|
|
Used in EDXLSitRepRoot
element / container
|
|
|
|
|
|
SitRep Use Cases,
EDXL-RM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
The
preparedBy/Reporter/Originator may be different from the sender. Synonyms
found in the NIMS SitRep: “Originator”, “Reporter”
|
|
|
Used in EDXLSitRepRoot
element / container
|
|
|
|
|
|
|
|
|
Contact-Role-Enumerations,
Report-DateTime-Information
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
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.
|
|
|
Used in EDXLSitRepRoot
element / container
|
|
|
|
|
|
|
|
|
Contact-Role-Enumerations,
Report-DateTime-Information
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
Found in
some local incident/situation reports.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A unique
number for reporting an incident or event, used to identify each new or
updated report instance. Used to support report tracking.
|
|
|
EXAMPLE:
reportNumber is “12345” reportVersion is “Initial” (of Report # 12345)
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This
indicates the current version of the specific SitRep MessageReportType report
being submitted from the same source (“authorizedBy”) for the same incident
or event. If only one SitRep will be
submitted, indicate BOTH “Initial” and “Final”.
Default value
list: ReportVersionDefaultValues
|
|
|
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>.
|
|
|
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
Report-DateTime-Information
|
|
|
|
|
|
|
|
|
|
|
|
reportTitle
is the designation of a more specific title for the SitRep report other than
or in addition to the title given as the value of the <sitRep> element.
|
|
|
Used to
give a more particular title to an incident
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
REQUIRED;
MAY be used more than once [1..*]
|
|
|
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.
|
|
|
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
ICS 209
(“IncidentNumber”)
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
MAY be used more than once [0..*]
|
|
|
A code
specifying the incident response lifecycle stage currently in effect
|
|
|
|
|
|
·
Default value
list: IncidentLifecycleDefaultValues
·
Used in SitRep
“SituationInformation” Report Type
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
·
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
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL; MAY be used
once and only once. [0..*]
|
|
|
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.
|
|
|
·
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.
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The code denoting the
importance and necessity of the SitRep message
|
|
|
·
The
<urgency>, <severity> and <reportConfidence> elements
collectively distinguish less
emphatic from more emphatic messages.
·
Default value
list: UrgencyDefaultValues
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
SitRep Use Cases, Common
Alerting Protocol (CAP)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
·
The
<urgency>, <severity> and <reportConfidence> elements
collectively distinguish less emphatic from more emphatic messages.
·
Default value
list: ConfidenceDefaultValues
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
SitRep Use Cases, Common
Alerting Protocol (CAP)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The code
denoting the severity of the subject incident or event.
|
|
|
·
The
<urgency>, <severity> and <reportConfidence> elements
collectively distinguish less emphatic from more emphatic messages.
·
Re-uses the same
element as used in EDXL CAP 1.2
·
Default value
list: SeverityDefaultValues
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
SitRep Use
Cases (not found in research, ICS or DHS forms)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A
structure representing the physical location and/or organization associated
with the <preparedBy> role, or associated with the location where the
Field Observation is taking place, i.e. “where I am”.
|
|
|
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning,
Incident-Resource-Commitment-Summary
|
|
|
|
|
|
|
|
|
|
|
|
General
description of what the officer in the <preparedBy> role needs or
expects, or a description of intended next step(s) of Incident Command. ActionPlan is assumed to relate to the next
operational period unless paired with a “StandardTimeFrame” defined by the
user.
|
|
|
Synonyms
of ActionPlan include “Way Forward,’” “Next Steps,” “Moving On”
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
National
Incident Management System (NIMS)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DateTime
of next contact or report planned by the <preparedBy> role to set
expectations for provision or receipt of updated or additional information.
|
|
|
|
|
|
Used in SitRep element /
container
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
REQUIRED;
MUST be used once and only once [1..1]
|
|
|
<report>
is the element used to create an instance of the IReport abstract type and
through it, to specify the EDXL-SitRep Report Type of the message in which it
is used.
|
|
|
|
|
|
<report> MUST declare
one of the five specific EDXL-SitRep Report Types:
·
fieldObservation
[0..1]: FieldObservationType
·
situationInformation
[0..1]: SituationInformationType
·
responseResourcesTotals
[0..1]: ResponseResourcesTotalsType
·
casualtyAndIllnessSummary
[0..1]: CasualtyAndIllnessSummaryType
·
managementReportingSummary
[0..1]: ManagementReportingSummaryType
|
|
|
|
|
|
Used
in the SitRep element / container
|
|
|
|
4.3
FieldObservation Report Type [comment?]
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.
|
|
|
|
|
xs:
complexType extends IReport
|
|
|
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.
|
|
|
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.
|
|
|
Used
in EDXL-SitRep FieldObservation report type.
|
|
|
|
|
|
·
observationLocation
[1..1]: ct:EDXLLocationType
·
immediateNeeds
[1..1]: ct:EDXLStringType
·
immediateNeedsCategory
[0..*]: ImmediateNeedsCategoryDefaultValues
·
observationText[1..1]:
xs:string
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
·
Needs the
highest degree of accuracy possible given the limitations of the situation.
·
Used in
EDXL-SitRep FieldObservation report type
|
|
|
|
|
|
|
|
|
Supporting
Elements: Location Information
|
|
|
|
|
|
|
|
|
|
|
|
A textual
description of any pressing needs that the observer feels must be dispatched
or provided urgently.
|
|
|
·
Intended to give
advance notice of Resource Needs.
·
Not intended to
replace EDXL-RM,
|
|
|
|
|
|
|
|
|
|
|
|
Coordination-with-EDXL-RM,
Response-Resource-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
MAY be used more than once [0..*]
|
|
|
A category
or classification of any pressing needs that the observer feels must be
dispatched or provided urgently.
|
|
|
|
|
|
Default value list:
ImmediateNeedsCategoryDefaultValues
|
|
|
|
|
|
|
|
|
Coordination-with-EDXL-RM,
Response-Resource-Information
|
|
|
|
|
|
|
|
|
|
|
|
Description of the situation being
observed and reported.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Coordination-with-EDXL-RM,
Response-Resource-Information
|
4.4
SituationInformation Report Type [comment?]
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 (Section 3.3)
·
Remarks
·
LocationSize (LocationInformation)
·
edxl-gsf [XML Structure] (LocationInformation)
·
edxl-ciq [XML Structure] (ContactInformation)
Note: The combination of edxl-gsf & edxl-ciq contain a
set of re-usable elements such as ContactDescription, ContactRole,
ContactLocation, EDXLLocationType, and
AdditionalContactInformation.
|
|
|
|
|
xs:complexType extends IReport
|
|
|
Identifies and describes
the incident with which the message is concerned
|
|
|
situationInformation structure is a choice:
{{{primaryIncidentInformation
[1..1]} {subIncidentInformation [0..*]}} | {subIncidentInformation [1..*]}}
[1..1]
|
|
|
Used
in EDXL-SitRep SituationInformation report type.
|
|
|
|
|
|
·
primaryIncidentInformation
[0..1]: IncidentInformationType
·
subIncidentInformation
[0..*]: SubIncidentKInformationType
|
|
|
|
|
|
|
|
|
primaryIncidentInformation
|
|
|
|
|
|
|
|
|
The
primaryIncidentInformation identifies and describes the initial incident.
|
|
|
|
|
|
Used in SitRep “Situation
Information” Report Type
|
|
|
|
|
|
|
|
|
|
4.4.1 SubIncidentInformationType [comment?]
SubIncidentInformationType elements are
sequences of subIncidents that describe complex incidents
|
|
SubIncidentInformationType
|
|
|
|
|
|
A sequence
of subincidents of type IncidentInformationType
|
|
|
|
|
|
|
|
|
|
|
|
subIncident [1..*]:
IncidentInformationType
|
|
|
|
|
|
|
4.4.2 IncidentInformationType [comment?]
IncidentInformationType elements identify
the key items common to all incidents such as Name, Type, Complexity, etc.
|
|
|
|
|
|
|
|
Identifies
elements common to all incidents
|
|
|
|
|
|
|
|
|
|
|
|
·
incidentName
[1..*]: xs:string
·
incidentKind
[0..*]: IncidentKindDefaultValues
·
incidentComplexity
[0..1]: IncidentComplexityDefaultValues
·
incidentStartDateTime
[0..1]: ct:EDXLDateTimeType
·
geographicSize
[1..1]: GeographicSizeType
·
disasterInformation
[0..*]: DisasterInformationType
·
incidentLocation
[1..1]: ct:EDXLLocationType
·
jurisdictionInformation
[0..*]: JurisdictionInformationType
·
incidentStaging
[0..*]: IncidentStagingType
|
|
|
SituationInformationType.primaryIncidentInformation,
SubIncidentInformationType
|
|
|
|
|
|
|
|
|
|
|
|
REQUIRED;
MAY be used more than once [1..*]
|
|
|
The name
assigned to the incident (often by the Incident Commmander or lead Agency).
|
|
|
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.
|
|
|
Used in SitRep
“SituationInformation” Report Type
|
|
|
|
|
|
ICS 201,
203, 207, 209, 215
|
|
|
Incident-Name;
Incident-Identifier
|
|
|
|
|
|
|
|
|
OPTIONAL;
MAY be used more than once [0..*]
|
|
|
General
type or category of Incident.
|
|
|
|
|
|
·
Default value
list: IncidentKindDefaultValues
·
Used in SitRep
“SituationInformation” Report Type
|
|
|
|
|
|
DHS
InitialSitRep, DHS Spot Report, ICS-209
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Information
indicating the complexity, complications, level of difficulty or
cross-profession / jurisdiction / organization aspects involved in addressing
or responding to the incident.
|
|
|
ICS-209
term = “Incident Type or Complexity Level”
|
|
|
·
Default value
list: IncidentComplexityDefaultValues
·
Used in SitRep
“Situation Information” Report type
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Date
and Time the Incident started or was first observed.
|
|
|
Always paired with the
element “Estimate” (Boolean) to indicate whether the DateTime is estimated
vs. known.
·
See Appendix C:
Time Elements
|
|
|
Used in SitRep “Situation
Information” element / container
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The
two-dimensional geographic footprint of the incident measured in meters
squared, providing the overall size of the incident in terms of geography.
|
|
|
·
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”
|
|
|
·
Used in SitRep
“Situation Information” Report Type
|
|
|
IncidentInformationType,
JurisdictionInformationType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
Used in SitRep “Situation
Information” Report Type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
MAY be used more than once [0..*]
|
|
|
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
|
|
|
|
|
|
Used in SitRep
“SituationInformation” Report Type
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
JurisdictionInformationType
|
|
|
REQUIRED;
MAY be used more than once (one for each Staging Area) [1..*]
|
|
|
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
|
|
|
|
|
|
Used in SitRep “Situation
Information” Report Type
|
|
|
IncidentInformationType,
ManagementReportingSummaryType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
MAY be used more than once (one for each Staging Area) [0..*]
|
|
|
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; always paired with IncidentStagingArea
|
|
|
|
|
|
Used in SitRep “Situation
Information” Report Type
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
IncidentStagingArea
[[1..1]: xs:string
·
incidentStagingAreaLocation
[1..1]: ct:EDXLLocationType
|
|
|
IncidentInformationType.incidentStaging
|
|
|
|
4.4.2.1
DisasterInformation Complex Type [comment?]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
disasterName
[1..1]: xs:string
·
disasterDeclarationAuthority
[1..1]: xs:string
·
disasterDeclarationDateTime
[1..1]: ct:EDXLDateTimeType
|
|
|
IncidentInformationType.disasterInformation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The name
assigned to the disaster that is associated with this incident by the
DisasterDeclarationAuthority.
Part of the
DisasterInformation XML structure.
|
|
|
|
|
|
Used in SitRep
“SituationInformation” Report Type
|
|
|
|
|
|
|
|
|
|
|
|
disasterDeclarationAuthority
|
|
|
|
|
|
|
|
|
The
organization, agency or authority that officially declared the disaster that
is associated with this incident.
Part of
the DisasterInformation XML structure.
|
|
|
|
|
|
Used in SitRep
“SituationInformation” Report Type
|
|
|
|
|
|
|
|
|
|
|
|
disasterDeclarationDateTime
|
|
|
|
|
|
|
|
|
The Date
and Time a formal disaster is declared by an authority
|
|
|
|
|
|
Used in SitRep “Situation
Information” Report Type
|
|
|
|
|
|
|
|
|
Report-DateTime-Information
|
4.5
ResponseResourcesTotals Report Type [comment?]
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.
|
|
ResponseResourcesTotalsType
|
|
|
xs:complexType extends IReport
|
|
|
|
|
|
responseResourcesTotals
structure consists of one or more repetitions of a choice:
{{resourceTotal [1..1]} |
{organizationAndAssignments[1..1]} [1..*]
|
|
|
|
|
|
|
|
|
·
resourceTotal
[1..*]: ResourceTotalType
·
organizationAndAssignments
[1..*]: OrganizationAndAssignmentsType
|
|
|
|
|
|
Response-Resource-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
MAY be used more than once [0..*]
|
|
|
The
current total count (available inventory) of a given resource.
|
|
|
|
|
|
|
|
|
ResponseResourcesTotalsType
|
|
|
|
|
|
Response-Resource-Information
|
|
|
organizationAndAssignments
|
|
|
OrganizationAndAssignmentsType
|
|
|
OPTIONAL;
MAY be used more than once [0..*]
|
|
|
IncidentCommand
Structure documentation and Assignments
|
|
|
|
|
|
|
|
|
ResponseResourcesTotalsType
|
|
|
|
|
|
Incident-Command-Structure,
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
branchDivisionGroup
[1..1]: ct:EDXLStringType
·
resource [1..*]:
ResourceCountType
|
|
|
ResponseResourcesTotalType.resourceTotal
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
Supported by the edxl-ciq
[XML Structure]
|
|
|
Used in EDXL-SitRep
ResponseResourceTotals Report Type.
|
|
|
|
|
|
|
|
|
Incident-Resouce-Commitment;
Incident-Resource-Operational-Planning; Incident-Command-Organization
|
|
|
|
|
|
|
|
|
REQUIRED;
MAY be used more than once [1..*]
|
|
|
Specific
individual named resource,
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
agencyOrganization
[1..1]: ct:EDXLStringType
·
resourceName
[1..1]: ct:EDXLStringType
·
resourceTypeCategoryKind
[0..1]: ct:ValueListType
·
resourceDetail
[0..1]: ResourceDetailType
·
isSufficient
[0..1]: xs:boolean
|
|
|
ResourceTotalType.resource
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Agency
or Organization contributing the resource(s) to the incident, perhaps through
mutual aid agreements.
An agency is
a type of organization, which is a division of government with a specific
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)
|
|
|
Supported
by the edxl-ciq [XML Structure]
|
|
|
Used in EDXL-SitRep
ResponseResourcesTotals Report Type
|
|
|
|
|
|
|
|
|
Incident-Resource-Commitment;
Incident-Resource-Operational-Planning;Incident-Command-Organization
|
|
|
|
|
|
|
|
|
|
|
|
A
name or title of the resource used for identification and tracking.
|
|
|
|
|
|
Used in EDXL-SitRep
ResponseResourcesTotals Report Type.
|
|
|
|
|
|
|
|
|
Response Resources-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Short reference to the name of the resource type,
category or kind associated with the resource name.
|
|
|
·
Similar
resources my be grouped together for this purpose (for example, do not list
every type of fire engine –rather, it may be advisable to list two
generalized types of engines, such as “structure fire engines” and “wildland
fire engines” with totals for each).
·
Examples:
–
Fixed wing cargo
aircraft
–
Mobile Field
Kitchen / Type II / Food & Water
–
“Decontamination”
unit
–
Type 1 Fire
Engine
–
Type 4
Helicopter
|
|
|
Used in EDXL-SitRep
ResponseResourcesTotals Report Type.
|
|
|
|
|
|
|
|
|
Response Resources-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Summary information, often rendered in “counts” about
resources involved in emergency operations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Response Resources-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
A “yes” or “no” value indicating whether or not a
given resource is sufficient to fill
current or projected requirements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Response Resources-Information
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
resourcePersonnelCount:
xs:unsignedInt [0..1]
·
unassignedResourcePersonnel:
xs:unsignedInt [0..1]
·
resourceRequiredCount:
xs:unsignedInt [0..1]
·
resourceCommittedCount:
xs:unsignedInt [0..1]
·
resourceOnHandCount:
xs:unsignedInt [0..1]
·
resourceStillNeededCount:
xs:unsignedInt [0..1]
·
resourceRequestedCount:
xs:unsignedInt [0..1]
·
dateTimeOrdered:
ct:EDXLDateTimeType [0..1]
·
requestedArrival:
ct:EDXLDateTimeType [0..1]
·
estimatedArrival:
ct:EDXLDateTimeType [0..1]
·
reportToLocation:
ct:EDXLLocationType [0..1]
·
overheadPosition:
ct:ValueKeyIntPairType [0..*]
·
workAssignment:
ct:EDXLStringType [0..1]
·
specialInstructions:
xs:string [0..1]
·
specialEquipmentAndSupplies:
xs:string [0..*]
·
additionalAssistingOrganizations:
xs:string [0..1]
·
resourceStatus:
ResourceStatusType [0..1]
|
|
|
ResourceCountType.resourceDetail
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The
personnel associated with or required to operate each required resource by
“Type/Category/Kind” provided by an “Agency or Organization
|
|
|
|
|
|
Used in EDXL-SitRep
ResponseResourcesTotals Report Type.
|
|
|
|
|
|
|
|
|
Incident-Resource-Commitment-Summary
|
|
|
[responseResourcesTotals.resourceTotal.resource.resourceDetail.]
unassignedResourcePersonnel
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The number
of additional individuals (or individuals on overhead) that are not assigned
to a specific resource by agency or organization.
|
|
|
|
|
|
Used in EDXL-SitRep
ResponseResourcesTotals Report Type
|
|
|
|
|
|
|
|
|
Incident-Resource-Commitment-Summary
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The number
of resources by “Type/Category/Kind” provided by an “Agency or Organization”,
required to meet a specified need or work assignment.
|
|
|
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Commitment-Summary
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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”.
|
|
|
EDXL-RM message data may be
used to provide transaction information which may be totaled to calculate
this count
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Commitment-Summary
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
·
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
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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”
|
|
|
Defined as
“ResourceOnHandCount” subtracted from the “ResourceCommittedCount”
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
EDXL-RM message data may be
used to provide transaction information which may be totaled to calculate
this count
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The
Date/Time that the resource was requested or ordered in order to fill the
specified need or work assignment.
|
|
|
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The DateTime when the “requested” / “ordered”
resource is requested to arrive at the “reportToLocation” (i.e. When the
resource is needed)
|
|
|
·
ICS uses the
term "delivery" vs. "arrival". “Arrival" is used
here because this applies to Human Resources also.
·
In EDXL-RM,
“RequestedArrival” is an enumerated value of element “ScheduleType”
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The DateTime when the “requested” / “ordered” resource is expected to arrive at its
“ReportTo” location
|
|
|
In
EDXL-RM, “EstimatedArrival l” is an enumerated value of element
“ScheduleType”
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The location where the resources are to report or be
delivered (e.g. “IncidentStagingArea”, “IncidentLocation”).
|
|
|
EDXL-RM
message data may be used to provide ReportToLocation information (See EDXL-RM
“ScheduleInformation” Element).
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
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
|
|
|
·
Overhead
Position Examples:
·
Division
Supervisor
·
Group Supervisor
·
Assistant Safety
Officer
·
Technical
Specialst
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Description
of the anticipated work assignments given to the resource
|
|
|
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Decision-Support-Instructions;
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Description
of any special instructions to the resource regarding their assignment,
reporting location or any other instructions.
|
|
|
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Decision-Support-Instructions;
Incident-Command-Organization
|
|
|
specialEquipmentAndSupplies
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
For each
“Branch/Division/Group/Location” / “WorkAssignment/SpecialInstructions”
combination, a listing of special equipment or supplies needed.
|
|
|
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Operational-Planning
|
|
|
additionalAssistingOrganizations
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.)
|
|
|
Examples
may include ambulance services, Red Cross, DHS, utility companies.
Do not
repeat any resources / organizations listed in the “Incident Resource
Commitment Summary”.
|
|
|
Used in EDXL-SitRep
“ResponseResourcesTotalsDetail” element group
|
|
|
|
|
|
|
|
|
Incident-Resource-Commitment-Summary
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
inventoryRefreshDateTime
[1..1]: ct:EDXLDateTimeType
·
deploymentStatus
[0..1]: DeploymentStatusDefaultValues
·
availability
[1..1]: xs:string
|
|
|
ResourceDetailType.resourceStatus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The
DateTime at which inventory records were last updated with current values.
|
|
|
|
|
|
Used in EDXL-SitRep ResponseResourceTotals
Report Type.
|
|
|
|
|
|
|
|
|
Incident-Resouce-Commitment;
Incident-Resource-Operational-Planning; Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The DeploymentStatus element is a value corresponding
to the value for a ValueListType supplied by the resource provider
Default value list:
DeploymentStatusDefaultValues
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Incident-Resouce-Commitment;
Incident-Resource-Operational-Planning; Incident-Command-Organization
|
|
|
|
|
|
|
|
|
|
|
|
Availability
provides information on whether or not a resource is available, and any
incidental information not otherwise provided that relates to resource
availability.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Incident-Resouce-Commitment;
Incident-Resource-Operational-Planning; Incident-Command-Organization
|
4.5.2 OrganizationAndAssignments
Complex Type [comment?]
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
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
commandStructure
[0..1]: ct:EDXLStringType
·
positionTitle
[0..1]: PositionDefaultValues
·
personName
[0..1]: ct:PersonDetailsType
·
branch [0..1]:
ct:ValueKeyType
·
reportsToPositionTitle
[0..1]: PositionDefaultValues
·
reportsToPersonName
[0..1]: ct:PersonDetailsType
·
reportsToAgency
[0..*]: ct:ValueListType
·
reportsToBranch
[0..1]: ct:ValueKeyType
|
|
|
ResponseResourcesTotalsType.organizationAndAssignments
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
·
Uses edxl-ciq
[XML Structure]
·
The SitRepRoot
contains common elements such as sentDateTime and forTimePeriod which is
associated with an Incident CommandStructure
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization,
Incident-Organization-and-Assignments
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
A position
name, role name or title of a professional that may fall at any level of the
Incident Command Structure hierarchy
Default
value list: PositionDefaultValues
|
|
|
·
Additional
elements that may be included with each PositionTitle include:
·
personName
·
agency
·
branch
·
reportToPositionTitle
·
reportToPersonName
·
reportToAgency
·
reportToBranch
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Container for person name
details
|
|
|
Same person with many types
(e.g. alias, pet name, nick name) of
names can be used by this container.
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.).
|
|
|
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
A position
name, role name or title of a professional that the current PositionTitle
Value reports to in the Incident Command Structure hierarchy
Default
value list: PositionDefaultValues
|
|
|
·
Additional
elements that may be included with each ReportsToPositionTitle include:
·
reportsToPersonName
·
reportsToAgency
·
reportsToBranch
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Name of
the person filling the ReportsToPositionTitle or role within the Incident
Command Structure hierarchy
|
|
|
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
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.)
|
|
|
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.)
|
|
|
|
|
|
|
|
|
OrganizationAndAssignmentsType
|
|
|
|
|
|
Incident-Command-Organization
|
4.6
CasualtyAndIllnessSummary Report Type [comment?]
The “Casualty and Illness Summary” Report Type
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 “Totals”, 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.
Non-normative example
|
|
Number This Reporting Period
|
|
|
|
|
|
Casualty & Illness Summary
Categories
|
|
Non-Responder Summary Count
|
|
|
Non-Responder Summary Count
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NumberOfWithInjury/Illness
|
|
|
|
|
|
|
|
|
|
|
NumberOfTrapped/In
need of rescue
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NumberOfSheltering
In Place
|
|
|
|
|
|
|
|
|
|
|
NumberInTemporaryShelters
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HaveReceivedMassImmunizationsCount
|
|
|
|
|
|
|
|
|
|
|
RequireMassImmunizationsCount
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Responder Summary Percentage:
|
|
|
|
|
|
Total number
of casualties affected
|
|
|
|
|
Non-Responder Summary Percentage:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CasualtyAndIllnessSummaryType
|
|
|
xs:complexType extends IReport
|
|
|
|
|
|
casualtyAndIllnessSummary structure is a choice:
{{summaryCount [1..1] |
{notifiableDiseaseNumbers [1..1]}} [1..*]
|
|
|
|
|
|
|
|
|
·
summaryCount
[1..1]: SummaryCountType
·
notifiableDiseaseNumbers
[1..1]: NotifiableDiseaseNumbersType
|
|
|
casualtyAndIllnessSummary
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CasualtyAndIllnessSummaryType
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
|
|
|
NotifiableDiseaseNumbersType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CasualtyAndIllnessSummaryType
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
casualtyAndIllnessCountCategory
[1..1]: CasualtyAndIllnessCountCategoryType
·
responderSummaryCount
[0..1]: xs:unsignedInt
·
nonResponderSummaryCount
[0..1]: xs:unsignedInt
·
responderSummaryCountToDate
[0..1]: xs:unsignedInt
·
nonResponderSummaryCountToDate
[0..1]:xs:unsignedInt
·
receivedMassImmunizations
[0..1]: ImmunizationCountType
·
requireMassImmunization
[0..1]: ImmunizationCountType
·
shelterCountEstimate[0..1]:
xs:unsignedInt
|
|
|
CasualtyAndIllnessSummaryType.summaryCount
|
|
|
|
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.
|
|
CasualtyAndIllnessCountCategoryType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
countCategory
[1..1]: CasualtyAndIllnessCountCategoryDefaultValues
·
remarks [0..1]:
ct:RemarksType
·
isEstimate
[0..1]: ct:EstimateType
|
|
|
SummaryCountType.casualtyAndIllnessCountCategory
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A type of
casualty or illness, used to collect counts and statistics by types of casualties.
Part of
the CasualtyAndIllnessSummaryCount XML structure.
Default
value list: CasualtyAndIllnessCountCategoryDefaultValues
|
|
|
A casualty
is any person impacted in some way by an emergency situation or disaster.
|
|
|
|
|
|
CasualtyAndIllnessCountCategoryType
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
For each
casualtyAndIllnessCountCategory, the count of Responder Casualties for this
reporting period.
Part of
the casualtyAndIllnessSummaryCount XML structure.
|
|
|
“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.
|
|
|
Used in EDXL-SitRep
“CasualtyAndIllnessSummary” Report Type
|
|
|
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
For each
casualtyAndIllnessCountCategory, the count of Non-Responder Casualties for
this reporting period.
Part of
the CasualtyAndIllnessCountCategoryType XML structure.
|
|
|
“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”.)
|
|
|
Used in EDXL-SitRep
CasualtyAndIllnessSummary Report Type.
|
|
|
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
responderSummaryCountToDate
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
For each
CasualtyAndIllnessCountCategory, the count of Non-Responder Casualties for
this incident to date.
Part of
the CasualtyAndIllnessCountCategoryType XML structure.
|
|
|
·
“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
|
|
|
Used in EDXL-SitRep
CasualtyAndIllnessSummary Report Type.
|
|
|
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
nonResponderSummaryCountToDate
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
For each
CasualtyAndIllnessCountCategory, the count of Non-Responder Casualties for
this incident to date.
Part of
the CasualtyAndIllnessSummaryCount XML structure.
|
|
|
·
“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
|
|
|
Used in EDXL-SitRep
CasualtyAndIllnessSummary Report Type.
|
|
|
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
count [1..1]:
xs:unsignedInt
·
remarks [0..1]:
ct:RemarksType
·
isEstimate
[0..1]: ct:EstimateType
|
|
|
SummaryCountType.receivedMassImmunizations
SummaryCountType.requireMassImmunizations
|
|
|
|
|
|
receivedMassImmunizations
|
|
|
|
|
|
|
|
|
The number
count of people who have received immunizations relevant specifically to
incident conditions and/or as part of incident operations.
|
|
|
This number is not included
in any Casualty and Illness Summary totals
|
|
|
Used in EDXL-SitRep
CasualtyAndIllnessSummary Report Type.
|
|
|
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
|
|
|
|
|
|
|
|
|
The
number of people who require immunizations relevant specifically to incident
conditions and/or as part of incident operations.
|
|
|
Count
in this element refers to number of people.
|
|
|
Used in EDXL-SitRep
CasualtyAndIllnessSummary Report Type.
|
|
|
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
|
|
|
|
|
|
|
|
|
|
|
The total
number of people projected to require shelter due to the incident, to assist
planning and matching of resources.
|
|
|
This number is not included
in any Casualty and Illness Summary totals
|
|
|
Used
in EDXL-SitRep CasualtyAndIllnessSummary Report Type.
|
|
|
|
|
|
|
|
|
Casualty-and-Illness-Summary
|
4.6.2 NotifiableDiseaseNumbers
Complex Type [comment?]
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”…
|
|
NotifiableDiseaseNumbersType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
diseaseSuspected
[1..1]: ct:ValueKeyType
·
probableCause
[1..1]: ct:EDXLStringType
·
countOfSuspectedCases
[1..1]: xs:unsignedInt
·
countOfConfirmedCases
[1..1]: xs:unsignedInt
|
|
|
CasualtyAndIllnessSummaryType.notifiableDiseaseNumbers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
Used in EDXL-SitRep
NotifiableDiseaseNumbers element group within the EDXL-SitRep
CasualtyAndIllnessSummary Report Type
|
|
|
NotifiableDiseaseNumbersType
|
|
|
|
|
|
Notifiable-Disease-Numbers
|
|
|
|
|
|
|
|
|
|
|
|
Description
of the most likely cause of the suspected disease.
|
|
|
|
|
|
Used in EDXL-SitRep
NotifiableDiseaseNumbers element group within the EDXL-SitRep
CasualtyAndIllnessSummary Report Type
|
|
|
NotifiableDiseaseNumbersType
|
|
|
|
|
|
Notifiable-Disease-Numbers
|
|
|
|
|
|
|
|
|
|
|
|
The number
of cases alleged but not confirmed of the suspected disease.
|
|
|
|
|
|
Used
in EDXL-SitRep NotifiableDiseaseNumbers element group within the EDXL-SitRep
CasualtyAndIllnessSummary Report Type
|
|
|
NotifiableDiseaseNumbersType
|
|
|
|
|
|
Notifiable-Disease-Numbers
|
|
|
|
|
|
|
|
|
|
|
|
The number
of cases officially confirmed of the suspected disease
|
|
|
|
|
|
Used
in EDXL-SitRep NotifiableDiseaseNumbers element group within the EDXL-SitRep
CasualtyAndIllnessSummary Report Type
|
|
|
NotifiableDiseaseNumbersType
|
|
|
|
|
|
Notifiable-Disease-Numbers
|
4.7
ManagementReportingSummary Report Type [comment?]
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
concern that overlap the other topical categories of situation information,
response resources and casualty information related to overall population
health.
The foregoing topical categories fall in the
SituationSummary Element Group, while the information more directly related to
making decisions is gathered into IncidentDecisionSupportInformation Element
Group.
This group contains.elements such as
ProjectedIncidentActivity, StrategicDiscussion,
PlannedActions.
|
|
ManagementReportingSummaryType
|
|
|
xs:complexType extends IReport
|
|
|
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, Infrastructure Affected
and Possible Cascading Effects.
|
|
|
managementReportingSummary
structure is a choice:
{{{situationSummary
[1..1]} {decisionSupportInformation [0..1]} {jurisdictionInformation [0..*]}}
|
{{decisionSupportInformation [1..1]} {jurisdictionInformation [0..*]}}
| {jurisdictionInformation
[1..*]}}
|
|
|
|
|
|
|
|
|
·
situationSummary[1..1]:
SituationSummaryType
·
decisionSupportInformation
[0..1]: DecisionSupportInformationType
·
jurisdictionInformation
[0..*]: JurisdictionInformationType
|
|
|
managementReportingSummary
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The element group gathered in SituationSummary
identifies situation status and describes 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,
Infrastructure Affected and Possible Cascading Effects.
|
|
|
|
|
|
|
|
|
ManagementReportingSummaryType
|
|
|
|
|
|
Incident-Response-Information
|
|
|
decisionSupportInformation
|
|
|
DecisionSupportInformationType
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
|
|
|
ManagementReportingSummaryType
|
|
|
|
|
|
Incident-Response-Information
|
|
|
|
|
|
JurisdictionInformationType
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
JurisdictionInformation
provides key information about incident command and the various organizations
involved in the response. Jurisdiction
Information is key to making quick decisions that do not exceed the authority
of the jurisdiction involved
|
|
|
|
|
|
|
|
|
ManagementReportingSummaryType,
IncidentInformationType
|
|
|
|
|
|
Incident-Response-Information
|
4.7.1 SituationSummary
Complex Type [comment?]
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
incidentCause
[1..1]: xs:string
·
significantEvents
[0..*]: SignificantEventsDefaultValues
·
damageAssessmentInformation
[0..1]: xs:string
·
primaryHazards
[0..1]: xs:string
·
hazMatIncidentReport
[1..1]: xs:any
·
extentOfContamination
[0..*]: ct:EDXLLocationType
·
generalPopulationStatus
[0..1]: xs:string
·
externalAffairs
[0..1]: ExternalAffairsType
·
humanLifeAndSafetyThreat
[0..1]: xs:string
·
lifeAndSafetyThreat
[1..*]: LifeAndSafetyThreatDefaultValues
·
incidentThreatSummaryAndRisk
[0..*]: xs:string
·
followOnIndication
[0..1]: xs:string
·
infrastructureAffected
[0..*]: InfrastructureAffectedDefaultValues
·
debrisManagement
[0..1]: DebrisManagementType
·
propertyDamage
[0..*]: PropertyDamageType
·
percentContained
[0..1]: ct:PercentageType
·
requestsForAdditionalSupport
[0..1]: xs:string
·
terrorismNexus
[0..1]: xs:string
·
weatherEffects
[0..1]: ct:WeatherInfoType
·
WMDEffects
[0..1]: xs:string
·
transportationSystems
[0..*]: ct:ValueKeyStringPairType
|
|
|
ManagementReportingSummaryType.situationSummary
|
|
|
|
|
|
|
|
|
|
|
|
REQUIRED;
once and only once [1..1]
|
|
|
The known
or suspected cause of the incident such as "tornado",
"wildfire", "bridge collapse", "parade",
"vehicle fire", "mass casualty", etc.
|
|
|
May be used with the common element “Estimate” to indicate whether
the size is estimated or known
|
|
|
|
|
|
|
|
|
|
|
|
Situation-Summary-Information Information Requirement #28
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
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.
Default
value list: SignificantEventsDefaultValues
|
|
|
Re-uses the element
“Remarks” to include specifics
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
damageAssessmentInformation
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
Schema defines it as:
<xs:complexType>
<xs:sequence>
<xs:any
namespace="##other" processContents="lax"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
The
geographical extent or “footprint” of the Contamination
|
|
|
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
General
status description of the general population in designated counties during
emergencies or disasters.
|
|
|
|
|
|
Used in EDXL-SitRep SituationSummary
element group within the EDXL-SitRep ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Information about
concerns that are external to the managementReportingSummary context that nevertheless needs to be taken
into account by the responder organizations and jurisdictions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Textual
description of hazards which are potentially dangerous and cause a threat to
human life and safety
|
|
|
·
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.
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
REQUIRED;
may be used more than once [1..*]
|
|
|
A
code indicating the current state of the threat and actions taken to manage
it.
|
|
|
·
Ensure not
duplicate with Situation Summary info, or ensure consistent terminology which
differentiates.
·
Re-uses the
element “Remarks” to include notes related to each code.
·
This element is
reflected by “humanLifeAndSafetyThreat” element in the “situationSummary”
element group
Default
value list: LifeAndSafetyThreatDefaultValues
|
|
|
·
Used in
EDXL-SitRep SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
·
Used in
EDXL-SitRep IncidentDecisionSupportInformation element group within the
EDXL-SitRep ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
incidentThreatSummaryAndRisk
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
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.
|
|
|
Note: See
EAS time frames also for potential adoption / reuse
Used
in conjunction with the “StandardTimeFrames” element (ValueListURN).
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Textual
description of known or anticipated incidents that will or may happen as a
result of, or otherwise immediately following, the current incident
|
|
|
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep ManagementReportingSummary
Report
Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
Infrastructure
and/or operational systems actually or most likely affected by disaster
|
|
|
The
purpose of this element is similar to the purpose of the threat element above
and in IncidentDecisionSupportInformation.
Default
value list: InfrastructureAffectedDefaultValues
|
|
|
Used in SitRep “Situation Summary” element /
container
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Tracks the details of
debris management.in the incident being reported
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
Tracks the
property categories that are threatened, damaged or destroyed by the disaster
or incident.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Estimated
percentage of the incident that has been contained, or where work to complete
response to the incident has been completed.
|
|
|
|
|
|
Used
in EDXL-SitRep SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
requestsForAdditionalSupport
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
General
description or summary of requests for additional resources or personnel –
high-level textual summary of “Response Resources”.
|
|
|
EDXL-RM
messages may be referred to, or used to provide this and/or more detailed
information.
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Textual
description of any connections that may exist with terrorist acts associated
with this incident.
|
|
|
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
·
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.
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Textual
descripton of any effects produced by weapons of mass destruction.
|
|
|
|
|
|
Used in EDXL-SitRep
SituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
ct:ValueKeyStringPairType
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
A list of
Transportation systems, such as surface roadways, inland waterways, airports,
etc., so that each may be associated with a status.
|
|
|
|
|
|
Used in
EDXL-SitRepSituationSummary element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
4.7.1.1
ExternalAffairs Complex Type [comment?]
The ExternalAffairs element group provides
information about concerns that are external to the ManagementReportingSummary
context that nevertheless need to be taken into account by the responder
organizations and jurisdictions.
|
|
|
|
|
|
|
|
Tracks
concerns that are external to the ManagementReportingSummary context
|
|
|
|
|
|
|
|
|
|
|
|
·
effectivePublicCommunication
[0..1]: xs:boolean
·
talkingPoints
[0..1]: xs:complexType
·
rumors [0..1]:
xs:complexType
|
|
|
SituationSummaryType.externalAffairs
|
|
|
|
|
|
effectivePublicCommunication
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Incident-Response-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
TalkingPoints
is the container element for individual Talking Points
|
|
|
|
|
|
<xs:complexType>
<xs:sequence>
<xs:element
name="talkingPoint" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
|
|
|
|
|
|
|
|
|
Incident-Response-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
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.
|
|
|
|
|
|
|
|
|
ExternalAffairsType.talkingPoints
|
|
|
|
|
|
Incident-Response-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
rumors is the container
element for individual Rumor elements
|
|
|
|
|
|
<xs:complexType>
<xs:sequence>
<xs:element name="rumor"
type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
|
|
|
|
|
|
|
|
|
Incident-Response-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
rumor 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.
|
|
|
|
|
|
|
|
|
ExternalAffairsType.rumors
|
|
|
|
|
|
Incident-Response-Information
|
4.7.1.2
DebrisManagement Complex Type [comment?]
Elements in the DebrisManagement ComplexType are used to
track the details of debris management.in the incident being reported.
|
|
|
|
|
|
|
|
Elements to track the
details of debris management
|
|
|
|
|
|
|
|
|
|
|
|
·
totalDebrisGeneratedCY
[0..1]: xs:unsignedInt
·
debrisClearedToDateCY
[0..1]: xs:unsignedInt
·
debrisNotYetClearedCY
[0..1]: xs:unsignedInt
·
daysToClearanceComplete
[0..1]: xs:unsignedInt
·
percentOfJurisdictionWithDebrisImpacts
[0..1]: ct:PercentageType
·
areasWithDebrisImpacts
[0..*]: ct:ValueListType
·
areasWhereWorkNotStarted
[0..*]: ct:ValueListType
·
debrisDisposedToDateCY
[0..1]: xs:unsignedInt
·
debrisNotYetDisposedCY
[0..1]: xs:unsignedInt
·
debrisStorageSitesPercentFilled
[0..1]: ct:PercentageType
·
daysToDisposalComplete
[0..1]: xs:unsignedInt
|
|
|
SituationSummaryType.debrisManagement
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
TotalDebrisGeneratedCY
stands for Total Debris Generated in the Incident being reported in the unit
of measure of Cubic Yards
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
DebrisClearedToDateCY
stands for Debris Cleared To Date in the Incident being reported in the unit
of measure of Cubic Yards.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
debrisNotYetClearedCY stands for Debris Not Yet Cleared in the
Incident being reported in the unit of measure of Cubic Yards.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
DaysToClearanceComplete
stands for number of Days To
Complete Clearance of Debris in the
Incident being reported.
|
|
|
|
|
|
Used in EDXL-DebrisManagement
ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
percentOfJurisdictionWithDebrisImpacts
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
AreasWithDebrisImpacts
stands for areas named in the ValueListType within the Jurisdiction in the
Incident being reported which have Debris Impacts.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
AreasWhereWorkNotStarted
stands for areas named in the ValueListType within the Jurisdiction in the
Incident being reported where work has not yet begun on Debris Removal.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
DebrisDisposedToDateCY
stands for Total Debris disposed of in the Incident being reported in the
unit of measure of Cubic Yards.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
DebrisNotYetDisposedCY
stands for Total Debris that has not yet been disposed of in the Incident
being reported in the unit of measure of Cubic Yards.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
debrisStorageSitesPercentFilled
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
DebrisStorageSitesPercentFilled stands for Percentage of Total space available in
Debris Storage Sites which has been filled in the Incident being
reported.
|
|
|
|
|
|
Used in
EDXL-DebrisManagement ComplexType within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
DaysToDisposalComplete
stands for number of days remaining to complete disposal of the debris in the
incident being reported..
|
|
|
|
|
|
Used in EDXL-DebrisManagement
ComplexType within the EDXL-SitRep ManagementReportingSummary Report Type
|
|
|
|
|
|
|
|
|
Situation
Summary-Information
|
|
|
|
|
|
|
|
|
Tracks
numbers and categories of property damage
|
|
|
|
|
|
|
|
|
|
|
|
·
numberDamaged
[1..1]: xs:unsignedInt
·
damageCategory
[1..1]: DamageCategoryDefaultValues
|
|
|
SituationSummaryType.propertyDamage
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Default
value list: DamageCategoryDefaultValues
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.7.2 DecisionSupportInformation
Complex Type [comment?]
Elements in the Incident DecisionSupportInformation
element group provide general management-level status and descriptive
information about resources, scope and status of the incident response, and
time and cost estimates such as projected # Of People To Be Sheltered, Anticipated Incident Management Completion
Date, and Emergency Response Issues /
Operational Activities.
Incident Decision Support information also
utilizes the following supporting elements:
·
LocationSizeUOM
·
StandardTimeFrames
·
Remarks
|
|
DecisionSupportInformationType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
projectedIncidentActivity
[0..1]: ct:ValueKeyStringPairType
·
projectedNumberToBeSheltered
[0..1]: xs:unsignedInt
·
criticalResourceNeeds
[0..*]: ct:ValueKeyStringPairType
·
projectedFinalIncidentSize
[0..1]: xs:unsignedLong
·
anticipatedCompletionDate
[0..1]: EstimatedDateType
·
projectedDemobilizationStartDate
[0..1]: EstimatedDateType
·
estimatedCostsToDate
[0..1]: EstimatedCostsType
·
projectedFinalCosts
[0..1]: EstimatedCostsType
·
emergencyResponseIssues
[0..*]: EmergencyResponseIssuesDefaultValues
·
strategicDiscussion
[0..1]: xs:string
·
plannedActions
[0..1]: xs:string
|
|
|
ManagementReportingSummaryType.decisionSupportInformation
|
|
|
|
|
|
projectedIncidentActivity
|
|
|
ct:ValueKeyStringPairType
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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, migrate,
or expand during the next operational period, or other factors that may cause
activity changes.
|
|
|
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
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
projectedNumberToBeSheltered
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The total
number of people projected to require shelter due to the incident, to assist
planning and matching of resources.
|
|
|
This is not a
“CasualtyAndIllnessCategory”. This
number is not included in any Casualty and Illness Summary totals
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
|
|
|
ct:ValueKeyStringPairType
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
A summary
of the overall resource needs required over 12-, 24-, 48- and 72-hour time frames,
and anticipated after 72-hours
|
|
|
Used in conjunction with the
“StandardTimeFrames” element (ValueListURN).
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
projectedFinalIncidentSize
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
An
estimate of the total physical area likely to be involved or affected over
the course of the incident.
|
|
|
·
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.
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
anticipatedCompletionDate
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The
Date/Time at which incident containment or control is expected, or at which
time the incident is expected to be closed or when significant incident
support will be discontinued.
|
|
|
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
projectedDemobilizationStartDate
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
The
Date/Time at which major or significant demobilization is likely.
|
|
|
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
date:
ct:EDXLDateTimeType
·
isEstimate:
ct:EstimateType
·
remarks:
ct:RemarksType
|
|
|
DecisionSupportInformationType.anticipatedCompletionDate,
DecisionSupportInformationType.projectedDemobilizationStartDate
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
·
Always used with
the CurrencyType common element (e.g. USD)
·
Used in
EDXL-SitRep IncidentDecisionSupportInformation element group within the
EDXL-SitRep ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
·
Always used with
the CurrencyType common element (e.g. USD)
·
Used in
EDXL-SitRep IncidentDecisionSupportInformation element group within the
EDXL-SitRep ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
|
|
|
Incident-Decision-Support-Information
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
costs:
ct:CurrencyType
·
isEstimate:
ct:EstimateType
·
remarks:
ct:RemarksType
|
|
|
DecisionSupportInformationType.estimatedCostsToDate,
DecisionSupportInformationType.projectedFinalCosts
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used more than once [0..*]
|
|
|
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.
|
|
|
Default values
list: EmergencyResponseIssuesDefaultValues
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
DHS SitRep
Update Report, DHS/FEMA SitRep Worksheet
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
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.
|
|
|
|
|
|
Used in EDXL-SitRep
IncidentDecisionSupportInformation element group within the EDXL-SitRep
ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
DHS
SitRep Update Report, DHS/FEMA SitRep Worksheet
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONAL;
may be used once and only once [0..1]
|
|
|
Discussion
of planned actions over the next operational period.
|
|
|
|
|
|
Used
in EDXL-SitRep IncidentDecisionSupportInformation element group within the
EDXL-SitRep ManagementReportingSummary Report Type
|
|
|
DecisionSupportInformationType
|
|
|
DHS
SitRep Update Report, DHS/FEMA SitRep Worksheet
|
|
|
|
|
|
|
|
|
|
|
|
Captures
qualified two-dimensional geographic
footprint measured in meters squared
|
|
|
|
|
|
|
|
|
|
|
|
·
size [1..1]:
xs:unsignedLong
·
isEstimate
[0..1]: ct:EstimateType
·
remarks [0..1]:
ct:RemarksType
|
|
|
IncidentInformationType.geographicSize
JurisdictionInformationType.geographicSize
|
|
|
|
4.8.2 JurisdictionInformation
Complex Type [comment?]
“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.
|
|
JurisdictionInformationType
|
|
|
|
|
|
An XML
structure containing 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.
|
|
|
|
|
|
|
|
|
|
|
|
·
name [1..1]:
xs:string
·
geographicSize
[1..1]: GeographicSizeType (1)
·
location [1..1]:
ct:EDXLLocationType
·
description
[1..1]: xs:string
|
|
|
IncidentInformationType.jurisdictionInformation
ManagementReportingSummaryType.jurisdictionInformation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
·
It is recognized
that this definition mixes two types of concepts:
·
Reference to an
organization or agency that has “Authority” over something (such as an
incident, or a set of identified resources).
Jurisdiction in this sense may be general, such as “federal”, “city”,
or “state”, or may be specific agency names such as “Warren County”, “US
Coast Guard”, “Panama City”, and “NYPD”.
·
Reference to a
pre-defined physical location or geo-political area
·
Though a
jurisdiction itself is not a person, role, or title, a jurisdiction has
assigned to it one or more government personnel with legal authority for
certain types of decision-making such as allocation of emergency resources
and invocation of mutual aid agreements.
|
|
|
·
Terms used on
ICS-209: “Incident Location
Information: Incident Jurisdiction”
·
Used in
EDXL-SitRep SituationInformation and ManagementReportingSummary” Report
Types.
|
|
|
JurisdictionInformationType
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
|
|
|
·
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”
|
|
|
|
|
|
Used in EDXL-SitRep
SituationInformation and ManagementReportingSummary” Report Types.
|
|
|
JurisdictionInformationType,
IncidentInformationType
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
Always paired with one “AffectedJurisdictionName”
|
|
|
Used in EDXL-SitRep
SituationInformation and ManagementReportingSummary” Report Types.
|
|
|
JurisdictionInformationType
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
Always paired with one “AffectedJurisdictionName”
|
|
|
Used in EDXL-SitRep
SituationInformation and ManagementReportingSummary” Report Types.
|
|
|
JurisdictionInformationType
|
|
|
|
|
|
Situation-Summary-Information
|
|
|
ReportVersionDefaultValues
|
|
|
|
|
|
Default
enumerated values for reportVersion
|
|
|
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”.
|
|
|
|
|
|
·
“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)
|
|
|
|
|
|
|
|
|
|
|
|
IncidentLifecycleDefaultValues
|
|
|
|
|
|
Default
enumerated values for incidentLifeCycle
|
|
|
|
|
|
|
|
|
·
“Preparedness”
·
“Response”
·
“Mitigation”
·
“Recovery”
|
|
|
|
|
|
SitRepType.incidentLifecyclePhase
|
|
|
|
|
|
|
|
|
|
|
|
Default
enumerated values for urgency
|
|
|
|
|
|
|
|
|
·
“Immediate” -
Responsive action SHOULD be taken immediately.
·
“Expected” -
Responsive action SHOULD be taken soon (within next hour).
·
“Future” -
Responsive action SHOULD be taken in the near future.
·
“Past” -
Responsive action is no longer required.
·
“Unknown” -
Urgency not known.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Default
enumerated values for reportConfidence
|
|
|
|
|
|
|
|
|
·
“HighlyConfident”
– Topmost level of confidence.
·
“SomewhatConfident”
– Medium level of confidence.
·
“Unsure” – Low
level of confidence.
·
“NoConfidence” –
Lack of confidence – Can be used to support cancellation of previous report
|
|
|
|
|
|
SitRepType.reportConfidence
|
|
|
|
|
|
|
|
|
|
|
|
Default
enumerated values for severity
|
|
|
|
|
|
|
|
|
·
“Extreme” -
Extraordinary threat to life or property.
·
“Severe” -
Significant threat to life or property.
·
“Moderate” -
Possible threat to life or property.
·
“Minor” -
Minimal threat to life or property.
·
“Unknown” -
Severity unknown
|
|
|
|
|
|
|
|
|
|
|
|
ImmediateNeedsCategoryDefaultValues
|
|
|
|
|
|
Default
enumerated values for immediateNeedsCategory
|
|
|
|
|
|
|
|
|
·
“EmergencyMedicalServices”
·
“FireAndHazardousMaterials”
·
“IncidentManagement”
·
“LawEnforcement”
·
“MassCare”
·
“MedicalAndPublicHealth”
·
“PublicWorks”
·
“SearchAndRescue”
|
|
|
|
|
|
FieldObservationType.immediateNeedsCategory
|
|
|
|
|
|
IncidentKindDefaultValues
|
|
|
|
|
|
Default
enumerated values for incidentKind
|
|
|
Inherited from EDXL-CAP
CategoryType
|
|
|
|
|
|
·
“Geophysical” -
Geophysical (inc. landslide)
·
“Meteorological”
- Meteorological (inc. flood)
·
“GeneralEmergency”
- General emergency
·
“Safety” -
Public safety
·
“Security” - Law
enforcement, military, homeland and local/private security
·
“RescueAndRecovery”
- Rescue and recovery
·
“Rescue” -
Rescue
·
“FireSupressionAndRescue
– Fire suppression and rescue
·
“Fire” - Fire
·
“MedicalAndPublicHealth”
- Medical and public health
·
“Health” - Health
·
“PollutionAndEnvironmentalHazard”
- Pollution and other environmental hazard
·
“PublicAndPrivateTransportation”
- Public and private transportation
·
“Transport” -
Transport
·
“UtilityTelecommunicationOtherNonTranspotInfrastructure”
- Utility, telecommunication, other non-transport infrastructure
·
“CBRNE” -
Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or
attack.
|
|
|
|
|
|
IncidentInformationType.incidentKind
|
|
|
|
|
|
IncidentComplexityDefaultValues
|
|
|
|
|
|
Default
enumerated values for incidentComplexity
|
|
|
|
|
|
|
|
|
·
“Complex” –
Public / Professional preparedness is low, Coordination Complexity and
involvement is high (local, regional, state and national)
·
“ModerateComplex”
– Public / Professional preparedness is moderate-high, Coordination
Complexity and involvement is high (local, regional, state, possibly
national).
·
“Moderate” –
Public / Professional preparedness is high, Coordination Complexity and
involvement is moderate (local, regional)
·
“Low” - Public /
Professional preparedness is high, Coordination Complexity and involvement is
low (local only)
|
|
|
|
|
|
IncidentInformationType.incidentComplexity
|
|
|
|
|
|
DeploymentStatusDefaultValues
|
|
|
|
|
|
Default
enumerated values for deploymentStatus
|
|
|
|
|
|
|
|
|
·
“Available”
·
“ConditionallyAvailable”
·
“EnRoute”
·
“AtHospital”
·
“NotAvailable”
·
“OnScene”
·
“Overdue”
·
“AvailableByPager”
·
“InQuarters”
·
“OnTheRadio”
·
“Transporting”
·
“WaitingResponse”
|
|
|
|
|
|
ResourceStatusType.deploymentStatus
|
|
|
|
|
|
|
|
|
|
|
|
Default
enumerated values for positionTitle
|
|
|
|
|
|
|
|
|
·
“CompensationClaimsUnitLeader”
·
“ProcurementUnitLeader”
·
“TimeUnitLeader”
·
“CostUnitLeader”
·
“FinanceAdministrationSectionChief”
·
“CommunicationsUnitLeader”
·
“MedicalUnitLeader”
·
“FoodUnitLeader”
·
“ServiceBranchDirector”
·
“GroundSupportUnitLeader”
·
“FacilitiesUnitDirector”
·
“SupplyUnitDirector”
·
“SupportBranchDirector”
·
“LogisticsSectionChief”
·
“StagingAreaManager”
·
“OperationsSectionChief”
·
“DemobilizationUnitLeader”
·
“DocumentationUnitLeader”
·
“ResourcesUnitLeader”
·
“SituationUnitLeader”
·
“PlanningSectionChief”
·
“TechnicalSpecialist”
·
“PublicInformationOfficer”
·
“SafetyOfficer”
·
“CommunicationsOfficer”
·
“LiaisonOfficer”
·
“IncidentCommander”
|
|
|
|
|
|
OrganizationAndAssignmentsType.positionTitle
OrganizationAndAssignmentsType.reportsToPositionTitle
|
|
|
|
|
|
CasualtyAndIllnessCountCategoryDefaultValues
|
|
|
|
|
|
Default
enumerated values for positionTitle
|
|
|
|
|
|
|
|
|
·
“Fatalities” –
Deceased
·
“Hospitalized” –
In-route or arrived at an Emergency Department or Hospital
·
“WithInjuryOrIllness”
– Physical or mental damage or sickness including those that may be caused
through a biological event such as an epidemic or an exposure to toxic or
radiological substances.
·
“TrappedOrInNeedOfRescue”
– In need of rescue due to incident or other conditions
·
“Missing” –
Cannot be located
·
“Evacuated” –
Accounted for and being evacuated from the scene
·
“ShelteringInPlace”
– Accounted for but sheltering in their original location at time of the
incident
·
“InTemporaryShelters”
– Accounted for and have been placed in a temporary shelter
·
“InQuarantine” –
Accounted for and under quarantine by authorities
·
“ReceivedMassImmunizations”
·
“RequireMassImmunizations”
|
|
|
|
|
|
CasualtyAndIllnessCountCategoryType.countCategory
|
|
|
|
|
|
SignificantEventsDefaultValues
|
|
|
|
|
|
Default
enumerated values for significantEvents
|
|
|
|
|
|
|
|
|
·
“RoadClosure”
·
“MassNotifications”
·
“Evacuation”
·
“ShelterInPlace”
·
“PowerOutage”
·
“TreeDown”
·
“StrandedVehicle”
·
“WaterLineBreak”
·
“WaterShortage”
·
“Quarantine”
·
“BridgeCollapse”
·
“BuildingCollapse”
·
“Deaths”
·
“Injuries”
·
“MassImmunizations”
·
“CleanupComplete”
·
“ResidentRepopulation”
·
“IncidentCommandTransition”
·
“Accomplishments”
|
|
|
|
|
|
SituationSummaryType.significantEvents
|
|
|
|
|
|
LifeAndSafetyThreatDefaultValues
|
|
|
|
|
|
Default
values for lifeAndSafetyThreat
|
|
|
|
|
|
|
|
|
·
“NoLikelyThreat”
- No likely threat to life and safety.
·
“PotentialFutureThreat”
- Potential future threat to life and safety.
·
“MassNotificationsInProgress”
- Mass notifications in progress regarding emergency situations, evacuations,
shelter in place, or other public safety advisories relating to this
incident. These may include use of
threat and alert systems such as the Emergency Alert System or a “reverse
911” system.
·
“MassNotificationsCompleted”
– “Casualty and Illness Summary” by Responder has been completed and
submitted for this “ForTimePeriod”
·
“NoEvacuationsImminent”
- Evacuations are not anticipated in the near future based on current
information.
·
“PlanningForEvacuation”
- Evacuation planning is underway in relation to this incident.
·
“PlanningForShelterInPlace”
- Planning is underway for shelter in place activities related to this
incident.
·
“EvacuationsInProgress”
- There are active evacuations in progress relating to this incident.
·
“ShelterInPlaceInProgress”
- There are active shelter- in-place actions in progress relating to this
incident.
·
“RepopulationInProgress”
- There is an active repopulation in progress relevant to this incident.
·
“MassImmunizationInProgress”
- There is an active mass immunization in progress relevant to this incident.
·
“MassImmunizationComplete”
- A mass immunization effort has been completed in specific relation to this
incident.
·
“QuarantineInProgress”
- There is an active quarantine in progress relative specifically to this
incident.
|
|
|
|
|
|
SituationSummaryType.lifeAndSafetyThreat
|
|
|
|
|
|
InfrastructureAffectedDefaultValues
|
|
|
|
|
|
Default
values for infrastructureAffected
|
|
|
|
|
|
|
|
|
·
“MassTransit”
·
“RoadsAndHighways”
·
“Railway”
·
“BridgesAndTunnels”
·
“Seaports”
·
“Waterways”
·
“Airports”
·
“Broadcast” -
(TV, Radio, etc.)
·
“Power”
·
“Water”
·
“Bridges”
·
“GasLines”
·
“Nuclear”
·
“ConduitsAndRaceways”
·
“CablingAndPatchPanels”
·
“PowerAndEnergy”
·
“AirConditioning”
·
“DrinkingWater”
·
“Sewage”
·
“Irrigation”
·
“WasteOrHazardousWaste”
·
“FloodControl”
- Dikes, Levees
·
“EarthMonitoringAndMeasurementNetworks”
- (Tidal, Meteorological, Seismometer, etc.)
·
“Postal”
·
“TelecommunicationsPhone”
·
“TelecommunicationsMobile”
·
“InternetBackbone”
·
“PrivateNetwork”
·
“Satellite”
·
“ElectronicCommunicationsNetworks”
·
“PersonalComputingServersAndDevices”
·
“TrainedPersonnel”
|
|
|
|
|
|
SituationSummaryType.infrastructureAffected
|
|
|
|
|
|
DamageCategoryDefaultValues
|
|
|
|
|
|
Default
values for damageCategory
|
|
|
|
|
|
|
|
|
·
Threatened
within 72 hours
·
Damaged
·
Destroyed
|
|
|
|
|
|
PropertyDamageType.damageCategory
|
|
|
|
|
|
EmergencyResponseIssuesDefaultValues
|
|
|
|
|
|
Default
values for emergencyResponseIssues
|
|
|
|
|
|
|
|
|
·
"ESF11AgricultureAndNaturalResources"
·
"ESF2Communications"
·
"ESF5EmergencyManagement"
·
"ESF12Energy"
·
"ESF15ExternalAffairs"
·
"ESF4Firefighting"
·
"ESF7LogisticsManagementResourceSupport"
·
"ESF14LongTermCommunityRecoveryAndMitigation"
·
"ESF6MassCareHousingAndHumanServices"
·
"ESF10OilAndHazardousMaterialsResponse"
·
"ESF8PublicHealthAndMedicalServices"
·
"ESF13PublicSafetyAndSecurity"
·
"ESF3PublicWorksAndEngineering"
·
"ESF9SearchAndRescue"
·
"ESF1Transportation"
|
|
|
|
|
|
DecisionSupportInformationType.emergencyResponseIssues
|
|
|
|
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 [comment?]
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 [comment?]
In summary, an EDXL-SitRep Message is one of the five (5)
report type elements specified in sections 3.4.2 to 3.4.6.
Requirements for an EDXL-SitRep Message Producer are given
in Section 5.4, and summarized here. An EDXL-SitRep Message Producer is a
software entity that produces conforming EDXL-SitRep Messages whenever an
EDXL-SitRep Message is expected.
5.3
Conformance as an EDXL-SitRep Message [comment?]
5.3.1 EDXL-SitRep
Message [comment?]
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 [comment?]
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.
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, Individual
Tom Ferrentino, Individual
Gary Ham, Individual
Don McGarry, MITRE Corporation
Brian Wilkins, MITRE Corporation
Rob Torchon, Individual
Appendix
B
EDXL-SituationReporting XML Schema [comment?]
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"?>
<!--
Emergency Data Exchange Language Situation
Reporting (EDXL-SitRep) Version 1.0
Working Draft WD22
26 July 2015
Copyright (c) OASIS Open 2015. All Rights
Reserved.
-->
<!-- edited with XMLSpy v2012 sp1 (x64)
(http://www.altova.com) by Donald P. McGarry et al.
(The Mitre Corporation) -->
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:edxl-gsf="urn:oasis:names:tc:emergency:edxl:gsf:1.0"
xmlns:ct="urn:oasis:names:tc:emergency:edxl:ct:1.0"
xmlns="urn:oasis:names:tc:emergency:EDXL:SitRep:1.0"
xmlns:ext="urn:oasis:names:tc:emergency:edxl:extension:1.0"
targetNamespace="urn:oasis:names:tc:emergency:EDXL:SitRep:1.0"
elementFormDefault="qualified"
attributeFormDefault="qualified">
<xs:import
namespace="urn:oasis:names:tc:emergency:edxl:ct:1.0"
schemaLocation="./edxl-ct-v1.0-wd05.xsd"/>
<xs:import
namespace="urn:oasis:names:tc:emergency:edxl:gsf:1.0"
schemaLocation="./edxl-gsf.v1.0.xsd"/>
<xs:import
namespace="urn:oasis:names:tc:emergency:edxl:extension:1.0"
schemaLocation="./edxl-ext-v1.0.xsd"/>
<xs:complexType name="IReport"
abstract="true">
<xs:sequence>
<xs:element name="extension"
type="ext:ExtensionType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--Complex Types in Document
Order-->
<xs:complexType
name="DisasterInformationType">
<xs:sequence>
<xs:element
name="disasterName" type="xs:string"/>
<xs:element
name="disasterDeclarationAuthority" type="xs:string"/>
<xs:element
name="disasterDeclarationDateTime"
type="ct:EDXLDateTimeType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="IncidentStagingType">
<xs:sequence>
<xs:element
name="incidentStagingArea" type="xs:string"/>
<xs:element
name="incidentStagingAreaLocation"
type="ct:EDXLLocationType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="ResourceTotalType">
<xs:sequence>
<xs:element
name="branchDivisionGroup" type="ct:EDXLStringType"/>
<xs:element
name="resource" type="ResourceCountType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="ResourceStatusType">
<xs:sequence>
<xs:element
name="inventoryRefreshDateTime"
type="ct:EDXLDateTimeType"/>
<xs:element
name="deploymentStatus"
type="DeploymentStatusDefaultValues" minOccurs="0"/>
<xs:element
name="availability" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="ResourceCountType">
<xs:sequence>
<xs:element
name="agencyOrganization" type="ct:EDXLStringType"/>
<xs:element name="resourceName"
type="ct:EDXLStringType"/>
<xs:element
name="resourceTypeCategoryKind" type="ct:ValueListType"
minOccurs="0"/>
<xs:element
name="resourceDetail" type="ResourceDetailType"
minOccurs="0"/>
<xs:element name="isSufficient"
type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="ResourceDetailType">
<xs:sequence>
<xs:element
name="resourcePersonnelCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element name="unassignedResourcePersonnel"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element
name="resourceRequiredCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="resourceCommittedCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="resourceOnHandCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="resourceStillNeededCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="resourceRequestedCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="dateTimeOrdered" type="ct:EDXLDateTimeType"
minOccurs="0"/>
<xs:element
name="requestedArrival" type="ct:EDXLDateTimeType"
minOccurs="0"/>
<xs:element
name="estimatedArrival" type="ct:EDXLDateTimeType"
minOccurs="0"/>
<xs:element
name="reportToLocation" type="ct:EDXLLocationType"
minOccurs="0"/>
<xs:element
name="overheadPosition" type="ct:ValueKeyIntPairType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="workAssignment" type="ct:EDXLStringType"
minOccurs="0"/>
<xs:element
name="specialInstructions" type="xs:string"
minOccurs="0"/>
<xs:element
name="specialEquipmentAndSupplies" type="xs:string"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="additionalAssistingOrganizations" type="xs:string"
minOccurs="0"/>
<xs:element
name="resourceStatus" type="ResourceStatusType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="OrganizationAndAssignmentsType">
<xs:sequence>
<xs:element
name="commandStructure" type="ct:EDXLStringType"
minOccurs="0"/>
<xs:element
name="positionTitle" type="PositionDefaultValues"
minOccurs="0"/>
<xs:element
name="personName" type="ct:PersonDetailsType"
minOccurs="0"/>
<xs:element name="branch"
type="ct:ValueKeyType" minOccurs="0"/>
<xs:element
name="reportsToPositionTitle" type="PositionDefaultValues"
minOccurs="0"/>
<xs:element
name="reportsToPersonName" type="ct:PersonDetailsType"
minOccurs="0"/>
<xs:element
name="reportsToAgency" type="ct:ValueListType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="reportsToBranch" type="ct:ValueKeyType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="ImmunizationCountType">
<xs:sequence>
<xs:element name="count"
type="xs:unsignedInt" />
<xs:element name="remarks"
type="ct:RemarksType" minOccurs="0"/>
<xs:element
name="isEstimate" type="ct:EstimateType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="SummaryCountType">
<xs:sequence>
<xs:element
name="casualtyAndIllnessCountCategory"
type="CasualtyAndIllnessCountCategoryType"/>
<xs:element
name="responderSummaryCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="nonResponderSummaryCount" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="responderSummaryCountToDate" type="xs:unsignedInt" minOccurs="0"/>
<xs:element
name="nonResponderSummaryCountToDate" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="receivedMassImmunizations"
type="ImmunizationCountType"
minOccurs="0"/>
<xs:element name="requireMassImmunizations"
type="ImmunizationCountType" minOccurs="0"/>
<xs:element
name="shelterCountEstimate" type="xs:unsignedInt"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="NotifiableDiseaseNumbersType">
<xs:sequence>
<xs:element
name="diseaseSuspected" type="ct:ValueKeyType"/>
<xs:element
name="probableCause" type="ct:EDXLStringType"/>
<xs:element
name="countOfSuspectedCases" type="xs:unsignedInt"/>
<xs:element name="countOfConfirmedCases"
type="xs:unsignedInt"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="DebrisManagementType">
<xs:sequence>
<xs:element
name="totalDebrisGeneratedCY" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="debrisClearedToDateCY" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="debrisNotYetClearedCY" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="daysToClearanceComplete" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="percentOfJurisdictionWithDebrisImpacts"
type="ct:PercentageType"
minOccurs="0"/>
<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"/>
<xs:element
name="debrisNotYetDisposedCY" type="xs:unsignedInt" minOccurs="0"/>
<xs:element
name="debrisStorageSitesPercentFilled"
type="ct:PercentageType"
minOccurs="0"/>
<xs:element
name="daysToDisposalComplete" type="xs:unsignedInt"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="ExternalAffairsType">
<xs:sequence>
<xs:element
name="effectivePublicCommunication" type="xs:boolean"
minOccurs="0"/>
<xs:element
name="talkingPoints" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element
name="talkingPoint" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="rumors"
minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element
name="rumor" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SituationSummaryType">
<xs:sequence>
<xs:element
name="incidentCause" type="xs:string"/>
<xs:element
name="significantEvents"
type="SignificantEventsDefaultValues"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="damageAssessmentInformation"
type="xs:string" minOccurs="0"/>
<xs:element
name="primaryHazards" type="xs:string"
minOccurs="0"/>
<xs:element
name="hazMatIncidentReport">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other"
processContents="lax" minOccurs="0"/>
</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"/>
<xs:element
name="externalAffairs" type="ExternalAffairsType"
minOccurs="0"/>
<xs:element
name="humanLifeAndSafetyThreat" type="xs:string"
minOccurs="0"/>
<xs:element
name="lifeAndSafetyThreat"
type="LifeAndSafetyThreatDefaultValues"
maxOccurs="unbounded"/>
<xs:element
name="incidentThreatSummaryAndRisk" type="xs:string"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="followOnIndication" type="xs:string"
minOccurs="0"/>
<xs:element
name="infrastructureAffected"
type="InfrastructureAffectedDefaultValues"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="debrisManagement" type="DebrisManagementType"
minOccurs="0"/>
<xs:element
name="propertyDamage" type="PropertyDamageType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="percentContained" type="ct:PercentageType"
minOccurs="0"/>
<xs:element
name="requestsForAdditionalSupport" type="xs:string"
minOccurs="0"/>
<xs:element
name="terrorismNexus" type="xs:string"
minOccurs="0"/>
<xs:element
name="weatherEffects" type="ct:WeatherInfoType"
minOccurs="0"/>
<xs:element name="WMDEffects"
type="xs:string" minOccurs="0"/>
<xs:element
name="transportationSystems"
type="ct:ValueKeyStringPairType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PropertyDamageType">
<xs:sequence>
<xs:element
name="numberDamaged" type="xs:unsignedInt"/>
<xs:element
name="damageCategory"
type="DamageCategoryDefaultValues"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EstimatedCostsType">
<xs:sequence>
<xs:element name="costs"
type="ct:CurrencyType"/>
<xs:element
name="isEstimate" type="ct:EstimateType"
minOccurs="0"/>
<xs:element name="remarks"
type="ct:RemarksType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="EstimatedDateType">
<xs:sequence>
<xs:element
name="date"
type="ct:EDXLDateTimeType" />
<xs:element
name="isEstimate" type="ct:EstimateType"
minOccurs="0"/>
<xs:element name="remarks"
type="ct:RemarksType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="DecisionSupportInformationType">
<xs:sequence>
<xs:element
name="projectedIncidentActivity"
type="ct:ValueKeyStringPairType"
minOccurs="0"/>
<xs:element
name="projectedNumberToBeSheltered" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element
name="criticalResourceNeeds"
type="ct:ValueKeyStringPairType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="projectedFinalIncidentSize" type="xs:unsignedLong"
minOccurs="0"/>
<xs:element
name="anticipatedCompletionDate" type="EstimatedDateType"
minOccurs="0"/>
<xs:element
name="projectedDemobilizationStartDate" type="EstimatedDateType"
minOccurs="0"/>
<xs:element
name="estimatedCostsToDate" type="EstimatedCostsType"
minOccurs="0"/>
<xs:element
name="projectedFinalCosts" type="EstimatedCostsType"
minOccurs="0"/>
<xs:element
name="emergencyResponseIssues"
type="EmergencyResponseIssuesDefaultValues"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="strategicDiscussion" type="xs:string"
minOccurs="0"/>
<xs:element
name="plannedActions" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="IncidentInformationType">
<xs:sequence>
<xs:element
name="incidentName" type="xs:string"
maxOccurs="unbounded"/>
<xs:element
name="incidentKind" type="IncidentKindDefaultValues"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="incidentComplexity"
type="IncidentComplexityDefaultValues"
minOccurs="0"/>
<xs:element
name="incidentStartDateTime" type="ct:EDXLDateTimeType"
minOccurs="0"/>
<xs:element
name="geographicSize" type="GeographicSizeType" />
<xs:element
name="disasterInformation" type="DisasterInformationType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="incidentLocation" type="ct:EDXLLocationType"/>
<xs:element
name="jurisdictionInformation"
type="JurisdictionInformationType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="incidentStaging" type="IncidentStagingType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="CasualtyAndIllnessCountCategoryType">
<xs:sequence>
<xs:element
name="countCategory"
type="CasualtyAndIllnessCountCategoryDefaultValues"/>
<xs:element name="remarks"
type="ct:RemarksType" minOccurs="0"/>
<xs:element
name="isEstimate" type="ct:EstimateType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="JurisdictionInformationType">
<xs:sequence>
<xs:element
name="name" type="xs:string"/>
<xs:element
name="geographicSize" type="GeographicSizeType" />
<xs:element
name="location" type="ct:EDXLLocationType"/>
<xs:element
name="description" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType
name="GeographicSizeType">
<xs:sequence>
<xs:element name="size"
type="xs:unsignedLong"/>
<xs:element
name="isEstimate" type="ct:EstimateType"
minOccurs="0"/>
<xs:element name="remarks"
type="ct:RemarksType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!--/Complex Types in Documet
Order-->
<!--Root Element-->
<xs:element name="sitRep"
type="SitRepType"/>
<xs:complexType
name="SitRepType">
<xs:sequence>
<xs:element
name="messageID" type="ct:EDXLStringType"/>
<xs:element
name="preparedBy" type="ct:PersonTimePairType"/>
<xs:element
name="authorizedBy" type="ct:PersonTimePairType"/>
<xs:element
name="reportPurpose" type="ct:EDXLStringType"/>
<xs:element
name="reportNumber" type="xs:unsignedInt"/>
<xs:element
name="reportVersion" type="ReportVersionDefaultValues"/>
<xs:element
name="forTimePeriod" type="ct:TimePeriodType"/>
<xs:element
name="reportTitle" type="ct:EDXLStringType"
minOccurs="0"/>
<xs:element
name="incidentID"
type="ct:EDXLStringType"maxOccurs="unbounded"/>
<xs:element
name="incidentLifecyclePhase"
type="IncidentLifecycleDefaultValues"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="originatingMessageID" type="ct:EDXLStringType"
minOccurs="0"/>
<xs:element
name="precedingMessageID" type="ct:EDXLStringType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="urgency"
type="UrgencyDefaultValues" minOccurs="0"/>
<xs:element
name="reportConfidence" type="ConfidenceDefaultValues"/>
<xs:element
name="severity" type="SeverityDefaultValues"/>
<xs:element
name="reportingLocation" type="ct:EDXLLocationType"
minOccurs="0"/>
<xs:element
name="actionPlan" type="ct:EDXLStringType"
minOccurs="0"/>
<xs:element
name="nextContact" type="ct:EDXLDateTimeType"
minOccurs="0"/>
<xs:element name="report"
type="IReport"/>
</xs:sequence>
</xs:complexType>
<!--End Root-->
<!--Subreport Types-->
<xs:element
name="managementReportingSummary"
type="ManagementReportingSummaryType"/>
<xs:element
name="responseResourcesTotals"
type="ResponseResourcesTotalsType"/>
<xs:element
name="fieldObservation" type="FieldObservationType"/>
<xs:element
name="situationInformation"
type="SituationInformationType"/>
<xs:element
name="casualtyAndIllnessSummary"
type="CasualtyAndIllnessSummaryType"/>
<xs:complexType name="FieldObservationType">
<xs:complexContent>
<xs:extension
base="IReport">
<xs:sequence>
<xs:element
name="observationLocation" type="ct:EDXLLocationType"/>
<xs:element
name="immediateNeeds" type="ct:EDXLStringType"/>
<xs:element
name="immediateNeedsCategory"
type="ImmediateNeedsCategoryDefaultValues"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="observationText" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType
name="SituationInformationType">
<xs:complexContent>
<xs:extension
base="IReport">
<xs:sequence>
<xs:choice>
<xs:sequence>
<xs:element
name="primaryIncidentInformation"
type="IncidentInformationType"/>
<xs:element
name="subIncidentInformation"
type="SubIncidentInformationType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:element
name="subIncidentInformation"
type="SubIncidentInformationType"
maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType
name="ResponseResourcesTotalsType">
<xs:complexContent>
<xs:extension
base="IReport">
<xs:sequence>
<xs:choice
maxOccurs="unbounded">
<xs:element
name="resourceTotal" type="ResourceTotalType"/>
<xs:element
name="organizationAndAssignments"
type="OrganizationAndAssignmentsType"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType
name="CasualtyAndIllnessSummaryType">
<xs:complexContent>
<xs:extension
base="IReport">
<xs:sequence>
<xs:choice
maxOccurs="unbounded">
<xs:element
name="summaryCount" type="SummaryCountType"/>
<xs:element
name="notifiableDiseaseNumbers"
type="NotifiableDiseaseNumbersType"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType
name="ManagementReportingSummaryType">
<xs:complexContent>
<xs:extension
base="IReport">
<xs:sequence>
<xs:choice>
<xs:sequence>
<xs:element
name="situationSummary" type="SituationSummaryType"/>
<xs:element
name="decisionSupportInformation"
type="DecisionSupportInformationType"
minOccurs="0"/>
<xs:element
name="jurisdictionInformation"
type="JurisdictionInformationType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence>
<xs:element
name="decisionSupportInformation"
type="DecisionSupportInformationType"/>
<xs:element
name="jurisdictionInformation"
type="JurisdictionInformationType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:element
name="jurisdictionInformation"
type="JurisdictionInformationType"
maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType
name="SubIncidentInformationType">
<xs:sequence>
<xs:element
name="subIncident" type="IncidentInformationType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType
name="DeploymentStatusDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Available"/>
<xs:enumeration
value="ConditionallyAvailable"/>
<xs:enumeration
value="Enroute"/>
<xs:enumeration
value="AtHospital"/>
<xs:enumeration
value="NotAvailable"/>
<xs:enumeration
value="OnScene"/>
<xs:enumeration
value="Overdue"/>
<xs:enumeration
value="AvailableByPager"/>
<xs:enumeration
value="InQuarters"/>
<xs:enumeration
value="OntheRadio"/>
<xs:enumeration
value="Transporting"/>
<xs:enumeration
value="WaitingResponse"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="ReportVersionDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Initial"/>
<xs:enumeration
value="Update"/>
<xs:enumeration
value="Final"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="IncidentLifecycleDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Preparedness"/>
<xs:enumeration
value="Response"/>
<xs:enumeration value="Mitigation"/>
<xs:enumeration
value="Recovery"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="UrgencyDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Immediate"/>
<xs:enumeration
value="Expected"/>
<xs:enumeration
value="Future"/>
<xs:enumeration
value="Past"/>
<xs:enumeration
value="Unknown"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="ConfidenceDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="HighlyConfident "/>
<xs:enumeration
value="SomewhatConfident"/>
<xs:enumeration
value="Unsure"/>
<xs:enumeration
value="NoConfidence"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="SeverityDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Extreme"/>
<xs:enumeration
value="Severe"/>
<xs:enumeration
value="Moderate"/>
<xs:enumeration value="Minor"/>
<xs:enumeration
value="Unknown"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="ImmediateNeedsCategoryDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="EmergencyMedicalServices"/>
<xs:enumeration
value="FireAndHazardousMaterials"/>
<xs:enumeration
value="IncidentManagement"/>
<xs:enumeration
value="LawEnforcement"/>
<xs:enumeration
value="MassCare"/>
<xs:enumeration
value="MedicalAndPublicHealth"/>
<xs:enumeration
value="PublicWorks"/>
<xs:enumeration
value="SearchAndRescue"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="IncidentKindDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Geophysical"/>
<xs:enumeration
value="Meteorological"/>
<xs:enumeration
value="GeneralEmergency"/>
<xs:enumeration
value="Safety"/>
<xs:enumeration
value="Security"/>
<xs:enumeration value="RescueAndRecovery"/>
<xs:enumeration
value="Rescue"/>
<xs:enumeration
value="FireSupressionAndRescue"/>
<xs:enumeration
value="Fire"/>
<xs:enumeration
value="MedicalAndPublicHealth"/>
<xs:enumeration
value="Health"/>
<xs:enumeration
value="PollutionAndEnvironmentalHazards"/>
<xs:enumeration
value="PublicAndPrivateTransportation"/>
<xs:enumeration
value="Transport"/>
<xs:enumeration
value="UtilityTelecommunicationOtherNonTransportInfrastructure"/>
<xs:enumeration
value="CBRNE"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="PositionDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="CompensationClaimsUnitLeader"/>
<xs:enumeration
value="ProcurementUnitLeader"/>
<xs:enumeration
value="TimeUnitLeader"/>
<xs:enumeration
value="CostUnitLeader"/>
<xs:enumeration
value="FinanceAdministrationSectionChief"/>
<xs:enumeration
value="CommunicationsUnitLeader"/>
<xs:enumeration
value="MedicalUnitLeader"/>
<xs:enumeration
value="FoodUnitLeader"/>
<xs:enumeration
value="ServiceBranchDirector"/>
<xs:enumeration
value="GroundSupportUnitLeader"/>
<xs:enumeration value="FacilitiesUnitDirector"/>
<xs:enumeration
value="SupplyUnitDirector"/>
<xs:enumeration
value="SupportBranchDirector"/>
<xs:enumeration
value="LogisticsSectionChief"/>
<xs:enumeration
value="StagingAreaManager"/>
<xs:enumeration
value="OperationsSectionChief"/>
<xs:enumeration
value="DemobilizationUnitLeader"/>
<xs:enumeration
value="DocumentationUnitLeader"/>
<xs:enumeration
value="ResourcesUnitLeader"/>
<xs:enumeration value="SituationUnitLeader"/>
<xs:enumeration
value="PlanningSectionChief"/>
<xs:enumeration
value="TechnicalSpecialst"/>
<xs:enumeration
value="PublicInformationOfficer"/>
<xs:enumeration
value="SafetyOfficer"/>
<xs:enumeration
value="CommunicationsOfficer"/>
<xs:enumeration
value="LiaisonOfficer"/>
<xs:enumeration
value="IncidentCommander"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="CasualtyAndIllnessCountCategoryDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Fatalities"/>
<xs:enumeration
value="Hospitalized"/>
<xs:enumeration
value="WithInjuryOrIllness"/>
<xs:enumeration
value="TrappedOrInNeedOfRescue"/>
<xs:enumeration
value="Missing"/>
<xs:enumeration
value="Evacuated"/>
<xs:enumeration
value="ShelteringInPlace"/>
<xs:enumeration
value="InTemporaryShelters"/>
<xs:enumeration
value="InQuarantine"/>
<xs:enumeration value="ReceivedMassImmunizations"/>
<xs:enumeration
value="RequireMassImmunizations"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="SignificantEventsDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="RoadClosure"/>
<xs:enumeration
value="MassNotifications"/>
<xs:enumeration
value="Evacuation"/>
<xs:enumeration
value="ShelterInPlace"/>
<xs:enumeration
value="PowerOutage"/>
<xs:enumeration value="TreeDown"/>
<xs:enumeration
value="StrandedVehicle"/>
<xs:enumeration
value="WaterLineBreak"/>
<xs:enumeration
value="WaterShortage"/>
<xs:enumeration
value="Quarantine"/>
<xs:enumeration
value="BridgeCollapse"/>
<xs:enumeration
value="BuildingCollapse"/>
<xs:enumeration
value="Deaths"/>
<xs:enumeration
value="Injuries"/>
<xs:enumeration
value="MassImmunizations"/>
<xs:enumeration
value="CleanupComplete"/>
<xs:enumeration value="ResidentRepopulation"/>
<xs:enumeration
value="IncidentCommandTransition"/>
<xs:enumeration
value="Accomplishments"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="LifeAndSafetyThreatDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="NoLikelyThreat"/>
<xs:enumeration
value="PotentialFutureThreat"/>
<xs:enumeration
value="MassNotificationsInProgress"/>
<xs:enumeration
value="MassNotificationsCompleted"/>
<xs:enumeration
value="NoEvacuationsImminent"/>
<xs:enumeration
value="PlanningForEvacuation"/>
<xs:enumeration
value="PlanningForShelterInPlace"/>
<xs:enumeration
value="EvacuationsInProgress"/>
<xs:enumeration value="ShelterInPlaceInProgress"/>
<xs:enumeration
value="RepopulationInProgress"/>
<xs:enumeration
value="MassImmunizationInProgress"/>
<xs:enumeration
value="MassImmunizationComplete"/>
<xs:enumeration
value="QuarantineInProgress"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="InfrastructureAffectedDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="MassTransit"/>
<xs:enumeration
value="RoadsAndHighways"/>
<xs:enumeration
value="Railway"/>
<xs:enumeration
value="BridgesAndTunnels"/>
<xs:enumeration
value="Seaports"/>
<xs:enumeration
value="Waterways"/>
<xs:enumeration
value="Airports"/>
<xs:enumeration value="Broadcast"/>
<xs:enumeration
value="Power"/>
<xs:enumeration
value="Water"/>
<xs:enumeration
value="Bridges"/>
<xs:enumeration
value="GasLines"/>
<xs:enumeration
value="Nuclear"/>
<xs:enumeration value="ConduitsAndRaceways"/>
<xs:enumeration
value="CablingAndPatchPanels"/>
<xs:enumeration
value="PowerAndEnergy"/>
<xs:enumeration
value="AirConditioning"/>
<xs:enumeration
value="DrinkingWater"/>
<xs:enumeration value="Sewage"/>
<xs:enumeration
value="Irrigation"/>
<xs:enumeration
value="WasteOrHazardousWaste"/>
<xs:enumeration
value="FloodControl"/>
<xs:enumeration
value="EarthMonitoringAndMeasurementNetworks"/>
<xs:enumeration value="Postal"/>
<xs:enumeration
value="TelecommunicationsPhone"/>
<xs:enumeration
value="TelecommunicationsMobile"/>
<xs:enumeration
value="InternetBackbone"/>
<xs:enumeration
value="PrivateNetwork"/>
<xs:enumeration value="Satellite"/>
<xs:enumeration
value="ElectronicCommunicationsNetworks"/>
<xs:enumeration
value="PersonalComputingServersAndDevices"/>
<xs:enumeration
value="TrainedPersonnel"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="DamageCategoryDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="ThreatenedWithin72Hours"/>
<xs:enumeration
value="Damaged"/>
<xs:enumeration
value="Destroyed"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="EmergencyResponseIssuesDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="ESF11AgricultureAndNaturalResources"/>
<xs:enumeration
value="ESF2Communications"/>
<xs:enumeration
value="ESF5EmergencyManagement"/>
<xs:enumeration
value="ESF12Energy"/>
<xs:enumeration
value="ESF15ExternalAffairs"/>
<xs:enumeration
value="ESF4Firefighting"/>
<xs:enumeration
value="ESF7LogisticsManagementResourceSupport"/>
<xs:enumeration
value="ESF14LongTermCommunityRecoveryAndMitigation"/>
<xs:enumeration
value="ESF6MassCareHousingAndHumanServices"/>
<xs:enumeration
value="ESF10OilAndHazardousMaterialsResponse"/>
<xs:enumeration
value="ESF8PublicHealthAndMedicalServices"/>
<xs:enumeration
value="ESF13PublicSafetyAndSecurity"/>
<xs:enumeration
value="ESF3PublicWorksAndEngineering"/>
<xs:enumeration
value="ESF9SearchAndRescue"/>
<xs:enumeration
value="ESF1Transportation"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType
name="IncidentComplexityDefaultValues">
<xs:restriction
base="ct:ValueType">
<xs:enumeration
value="Complex"/>
<xs:enumeration value="ModerateComplex"/>
<xs:enumeration
value="Moderate"/>
<xs:enumeration
value="Low"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Appendix
C.1
Selecting values from lists [comment?]
The ValueList and ValueKey types are part of the EDXL Common
Types collection. They allow standards adopters to use topic specific lists of
values for elements such as raceEthnicity, fluenSpokenLanguages,
specialTransportationNeeds, etc.. Both types have identical structure, but
ValueList allows for selection of multiple values [1..*] in the list, whereas
ValueKey allows for selection of only one [1..1] value in the list.
When using a ValueList / ValueKey structure the user can
specify a user-defined list by URI (either using the “urn:...” format or the
more familiar “http://...” format) and then include user-defined values from
that list. This structure has several advantages: (a) it provides flexibility
for local communities to use community-defined terms and vocabulary; (b) it
allows for the external maintenance of local or standardized lists; and (c) it
avoids the problems inherent in attempting to constantly update hard-coded
enumerations in a specification.
An existing vetted list should be referenced for defaults,
but users could also reference their own value list.
Appendix
C.1.1
ValueListType [comment?]
The schema for ct:ValueListType is defined as
<xs:complexType
name="ValueListType">
<xs:sequence>
<xs:element
ref="ct:ValueListURI" minOccurs="1"
maxOccurs="1"/>
<xs:element
ref="ct:Value" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
and its application to the XML description of an element elementName
of type ct:ValueListType would be:
<elementName>
<ct:ValueListURI>valueListURI</ct:ValueListURI>
<ct:Value>value_1</ct:Value>
…
<ct:Value>value_n</ct:Value>
</elementName>
In the
Data Dictionary we describe examples of
elements of type ct:ValueListType by listing value assignments to valueListURI
and value_1, …, value_n.
So for
instance an example for “specialMedicalNeeds” is described by
-
valueListURI = urn:myagency:gov:ahrq:specialMedicalNeeds and
-
value_1 = Ventilator
-
value_2 = Oxygen
<specialMedicalNeeds>
<ct:ValueListURI>urn:myagency:gov:ahrq:specialMedicalNeeds</ct:ValueListURI>
<ct:Value>Ventilator</ct:Value>
<ct:Value>Oxygen</ct:Value>
</specialMedicalNeeds>
This example contains two special
needs, one whose value is “Ventilator” and one whose value is “Oxygen”. These
are notional needs created for this example. The needs are identified as values
from a list whose unique Uniform Reference Identifier (URI) is
“urn:myagency:gov:ahrq:specialMedicalNeeds”.
A note about ValueList: the multiplicity of ValueList can be a source
for confusion. Typically, 1 is the maximum number of occurrences of ValueList.
This means that at most one such list may occur for a given element; this does
not preclude the user from selecting multiple entries from that list (maxOccurs
= “unbounded”).
Appendix
C.1.2
ValueKeyType [comment?]
The schema for ValueKeyType is defined as
<xs:complexType
name="ValueKeyType">
<xs:sequence>
<xs:element ref="ct:ValueListURI"
minOccurs="1" maxOccurs="1"/>
<xs:element ref="ct:Value"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
and its application to the XML description of an element elementName
of type ct:ValueKeyType would be:
<elementName>
<ct:ValueListURI>valueListURI</ct:ValueListURI>
<ct:Value>value</ct:Value>
</elementName>
This example uses a published list of values and definitions
and selects one specific entry to describe the eyeColor of a patient:
-
valueListURI = urn:myagency:gov:OMG:eyeColors
-
value =
Green
<eyeColor>
<ct:ValueListURI>urn:myagency:gov:OMG:eyeColors</ct:ValueListURI>
<ct:Value>Green</ct:Value>
</eyeColor>
Following the approach in ValueList, we'd point ValueListURI to some
other list to make a different selection of eye colors available.
Appendix C.2 EDXL
Extensions [comment?]
The challenge when developing
standardized formats is to balance the need to define specific elements of
emergency information that we can all agree upon and yet provide flexibility
for local communities to include their particular information using their
familiar vocabulary. EDXL
addresses this concern by providing the common defined terms in the formal
standards for the former, and by providing extension mechanisms for the latter.
Typical needs are:
1.
Community
augmentation: community adds
new information that is associated with the EDXL standard. Examples: adding HL7
translation information to the TEP.
2.
List
augmentation: community adds
new values (enumerations) to the default set of values in the standard.
Example: adding FlightRisk value to the TEP contingencyMedicalSpecialityCode
list.
3.
List
replacement:: community
replaces the default set of values in the standard in its entirety. Example: defining TriageStatus with number codes instead of colors.
4.
List
redefinition: community
reassigns the meaning of the default set of values in the standard in its
entirety. Example: redefining the Black TriageCode to
mean actively dying but not yet deceased.
EDXL combines the
CommunityExtension mechanism with the ValueList and ValueKey types to deal with
these needs. CommunityExtension addresses need 1.; ValueList / ValueKey address
need 3. ; and combined they address needs 2. and 4.
For more details about
EDXL Extensions and usage guidance, refer to the white paper [EDXL
Extensions] referenced in section 1.6 above.
A “CommunityExtension”, or simply
“Extension”, is a term used to describe supplemental message information that a
community wants to add to the otherwise standard message information normally
contained within an EDXL standard message. It is defined by the ExtensionType
which consists of a [1..*] set of name/value pairs.
The schema for ExtensionType is defined as
<xs:complexType name="ExtensionType">
<!-- Base type to allow
communities to extend/augment an EDXL data standard -->
<xs:sequence>
<xs:element
name="community" type="xs:anyURI">
<!-- Unique
community identifier -->
</xs:element>
<xs:element
name="id" type="xs:anyURI">
<!-- Unique
identifier for this extension -->
</xs:element>
<xs:element
name="parameter" type="ext:ParameterType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
where "ParameterType" is defined
as a group of elements used to extend/augment
the data standard
<xs:sequence>
<xs:element
name="nameURI" type="ext:ParameterNameType">
<!-- Unique
identifier of a parameter -->
</xs:element>
<xs:element
name="value" type="ext:ParameterValueType"
maxOccurs="unbounded"/>
</xs:sequence>
with
"ParameterNameType" being defined as a URI with optional xPath
attribute
and
"ParameterValueType" being defined as a ct:EDXLStringType"
with optional "uom" attribute.
Its application to the XML description of an element elementName
of type ext:ExtensionType would be:
<ext:ExtensionType
xmlns=”urn:oasis:names:tc:emergency:edxl:extension:1.0”>
<community>communityURI</community>
<id>extensionURI</id>
<parameter>
<nameURI>name</nameURI>
<value>value</value>
</parameter>
...
<parameter> … </parameter>
</ext:ExtensionType>
If that extension is to be used for adding a
community specific item in an enumeration, we indicate this by adding
<xsd:enumeration
value="ExtensionValue"/>
to the enumeration affected.
Note that this mechanism should be used only for required elements –
if an element is optional, it could be completely replaced by any community
extension, with its own name and structure.
Note also that for each example we assume
that the schema contains the following element to allow for adding extensions:
<xsd:element
name="extension"
type="ext:ExtensionType"
minOccurs="0" maxOccurs="unbounded"/>
Appendix
C.2.1
Community augmentation [comment?]
The following example illustrates the use of
ExtensionType to build a community
specific “layer” .
Example:
adding an “earthquake layer” to an EDXL standard
-
XML invocation:
<extension>
<community>http://www.myCommunity.org/layers/earthquake/</community>
<id>earthquakeLayer</id>
<parameter>
<nameURI>http://example/layers/earthquake/Magnitude</nameURI>
<value
uom=”http://example/layers/earthquake/RichterScale”>5.3</value>
</parameter>
<parameter>
<nameURI>http://example/layers/earthquake/EventTime</nameURI>
<value>2010-08-30T23:25:40+00:00</value>
</parameter>
<parameter>
<nameURI>http://example/layers/earthquake/Depth</nameURI>
<value
uom=”http://qudt.org/vocab/unit/MileInternational>38.7</value>
</parameter>
</extension>
Appendix
C.2.2
List augmentation [comment?]
If the list is defined as a ValueList or a
ValueKey, then use the corresponding mechanisms described above to point to
revised lists. If the list is defined as an enumeration, then the augmentation
can be achieved with the Extension mechanism.
The following example illustrates the use of
ExtensionType to add community specific
enumeration(s).
Example: adding “ReleasedForRehab” and “PostRehabRecidivismt” o
PatientCurrentDispositionDefaultValues enumeration in TEP
-
schema
particulars:
<xsd:simpleType
name="PatientCurrentDispositionDefaultValues">
<xsd:restriction
base="ct:EDXLStringType">
<xsd:enumeration
value="Discharged "/>
<xsd:enumeration
value="Transferred"/>
<xsd:enumeration
value="Deceased"/>
<xsd:enumeration
value="NoTreatmentRequired"/>
<xsd:enumeration
value="RefusedCare"/>
<xsd:enumeration
value="TreatedAndReleased"/>
<xsd:enumeration
value="TreatedAndTransferredCare"/>
<xsd:enumeration
value="TreatedAndTransported"/>
<xsd:enumeration
value="Admitted"/>
<xsd:enumeration
value="TreatedAndTransportedToHospital"/>
<xsd:enumeration
value="Pending-Ongoing"/>
<xsd:enumeration
value="ExtensionValue"/>
</xsd:restriction>
</xsd:simpleType>
and some URI (e.g.
www.patientDispositionExtension.org), enumerates the additional values:
<xsd:restriction
base=”ct:EDXLStringType”>
<xsd:enumeration
value=”ReleasedForRehab”/>
<xsd:enumeration
value=”PostRehabRecidivism”/>
</xsd:restriction>
-
XML
invocations:
<patientCurrentDisposition>ExtensionValue</patientCurrentDisposition>
...
<extension>
<community>http://www.patientDispositionExtension.org</community>
<id>specialDispositionRehab</id>
<parameter>
<nameURI
xPath=”/.../patientCurrentDisposition”>
http://example/US/EMS/dispositionCodes
</nameURI>
<value>ReleasedForRehab</value>
</parameter>
</extension>
Appendix
C.2.3
List replacement [comment?]
If the list is defined as a ValueList or a
ValueKey, then use the corresponding mechanisms described above to point to a
replacement list. If the list is defined as an enumeration, then the
replacement can be achieved with the Extension mechanism.
Example: the default triage codes are
{“Red", "Yellow", "Green, "Blue",
"Black" and "ExtensionValue"}. To allow for the use of
“Purple” from a different list of values, the TEP message would look like:
<TEPMessage>
<extension>
<community>http://example/US/EMS</community>
<id>layer2</id>
<parameter>
<nameURI
xPath="./patient/patientEncounter/patientCare/triageStatus"> http://example/US/EMS/triageCodes
</nameURI>
<value>Purple</value>
</parameter>
</extension>
...
<patient>
<patientEncounter>
<patientCare>
<triageStatus>ExtensionValue</triageStatus>
</patientCare>
</patientEncounter>
</patient>
</TEPMessage>
Appendix
C.2.4
List redefinition [comment?]
If the list is defined as a ValueList or a
ValueKey, then use the corresponding mechanisms described above to point to
list redefinitions. If the list is defined as an enumeration, then the
redefinition can be achieved with the Extension mechanism. Note that list
redefinition may pose significant risk to interoperability and therefore,
whether the list is completely redefined or only partially, best practices
suggest that the extension mechanism must be used, to signal that risk.
Example: if one or more triage values are
the same but have different meaning, then we use a redefined list with
Extension:
<TEPMessage>
<extension>
<community>http://example/US/EMS</community>
<id>layer2</id>
<parameter>
<nameURI
xPath=”./patient/patientEncounter/patientCare/triageStatus”>
http://example/US/EMS/triageCodes
</nameURI>
<value>Black</value>
</parameter>
</extension>
…
<patient>
<patientEncounter>
<patientCare>
<triageStatus>ExtensionValue</triageStatus>
</patientCare>
</patientEncounter>
</patient>
</TEPMessage>
Example code for each of the Situation Reports contained in
this specification are available at:
http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/csd01/schemas-and-examples/
These examples show all required and optional elements for
each of the reports.
Appendix
D.1
ICS209 Web Form Example [comment?]
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
|
|
|
|
|
|
|
|
|
Major Revision Working Draft
|
|
|
|
|
Major Revision Working Draft
|
|
|
|
|
Major Revision Working Draft submitted for Emergency Management Technical
Committee approval as Committee Specification Draft
|
|
|
|
|
Major Revision Working Draft submitted for Emergency Management
Technical Committee approval as Committee Specification Draft
|
|
|
20 Feb. - 25 June 2015
23 July 2015
|
|
Major revision + document rebuild
for SC review;
Added “Part of” field in Element
tables of Data Dictionary
|
|
|
|
|
Clean up comments;
adapt/restructure schemas
|
|
|
|
|
|
