From Wikipedia, the free encyclopedia

The Emergency Data Exchange Language (EDXL) is a suite of XML-based messaging standards that facilitate emergency information sharing between government entities and the full range of emergency-related organizations. EDXL standardizes messaging formats for communications between these parties. EDXL was developed as a royalty-free standard by the OASIS International Open Standards Consortium.[1]

EDXL was designed to enable information about life-saving resources to be shared across local, state, tribal, national and non-governmental organizations. Implementation of EDXL standards aims to improve the speed and quality of coordinated response activities by allowing the exchange of information in real time.


EDXL is advanced by the OASIS Emergency Management Technical Committee,[2] a group that was formed in 2003 and remains open to participation from organizations, agencies, and individuals from around the world. EDXL is based on detailed requirements and draft specifications provided to OASIS by emergency practitioners, with support from the Emergency Interoperability Consortium,[3] through a project sponsored by the United States Department of Homeland Security’s Disaster Management E-Gov Initiative.

EDXL-DE was approved as an OASIS Standard in 2006; EDXL-RM and –HAVE were approved as OASIS Standards in 2008.

Implementation of EDXL is promoted by the OASIS Emergency Management Adoption Committee, which was formed in 2009.


The EDXL suite comprises a number of individual standards. Each standard is elaborated in the following sub-sections:

EDXL-DE (Distribution Element)[edit]


EDXL-DE (Distribution Element)[4] OASIS Standard, an XML-based header or wrapper that provides flexible message-distribution for emergency information systems’ data sharing. Messages may be exchanged by specific recipients, by a geographic area, or by other codes such as incident and agency type (police, fire, etc.). Any content payload can be distributed using the DE, not just EDXL messages.


The primary purpose of the Distribution Element is to facilitate the routing of any properly formatted XML emergency message to recipients. The Distribution Element may be thought of as a "container". It provides the information to route "payload" message sets (such as Alerts or Resource Messages), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs.


Although there is an XML schema for EDXL-DE, there are some "business rules" or conformance rules that the developer must comply to in order to be considered conformant / compliant to the EDXL-DE Standard. Here are a list of the compliance rules from the EDXL-DE standard document:

Element Name Schema Data Type Restriction Comments Notes
senderID string In the form actor@domain-name In the format of an email address: <string w/o @>'@'<valid domain> Should be valid domain - In the "format" of an email; can't have commas
dateTimeSent dateTime The Date Time combination must include the offset time for time zone.
language string Valid language values are supplied in the ISO standard [RFC3066] can be en-US or EN or both in the form char[2] OR char[2]'-'char[2]
distributionReference string Comma delimited string consisting of a valid dist. ID, senderID, and dateTimeSent
circle string In the form lat,lon<space>radius Lat/lon is WGS84. Radius is in km
polygon string Must be a valid polygon. Must be in the form list{lat,lon<space>} No trailing space on the last point
polygon string Ring Orientation Follow the "Left Hand Rule" for exterior linear ring orientation? Not intersecting itself
country string Two character ISO 3166-1 country code Two characters
subdivision string Iso3166-1’-‘char[3] subdivision code Should be in the form char[2]’-‘char[1-3] Two characters '-' 1-3 Characters
locCodeUN string Iso3166-1’-‘UNLOCCODE Should be in the form char[2]’-‘char[3] 5 characters alphanumeric
digest string Result of SHA-1 hash on payload data So the result of the hash is just 160 bits. String must be a Hexadecimal representation of the hash result.
keyXMLContent string Must be explicitly namespaced as defined in the closing contentobject block It is correct that the XML data itself need to be within a separate namespace (not the entire content object). keyXMLContent must be well-formed
embeddedXMLContent Example string Must be explicitly namespaced as defined in the closing contentobject block It is correct that the XML data itself need to be within a separate namespace (not the entire content object). embeddedXMLContent must be well-formed
DistributionID string no commas


The Disaster Management eGov Initiative of the Department of Homeland Security (DHS) determined in 2004 to launch a project to develop interagency emergency data communications standards. It called together a group of national emergency response practitioner leaders and sought their guidance on requirements for such standards. In June, 2004 the first such meeting identified the need for a common distribution element for all emergency messages. Subsequent meetings of a Standards Working Group developed detailed requirements and a draft specification for such a distribution element (DE). During the same period the DM Initiative was forming a partnership with industry members of the Emergency Interoperability Consortium (EIC) to cooperate in the development of emergency standards. EIC had been a leading sponsor of the Common Alerting Protocol (CAP). Both organizations desired to develop an expanded family of data formats for exchanging operational information beyond warning. EIC members participated in the development of the DE, and in the broader design of the design of a process for the development of additional standards. This was named Emergency Data Exchange Language (EDXL). The goal of the 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 will accomplish this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession is involved. It is not just an "emergency management" domain exercise. It is a national effort including a diverse and representative group of local, state and federal emergency response organizations and professionals, following a multi-step process. Just as a data-focused effort targets shared data elements, the EDXL process looks for shared message needs, which are common across a broad number of organizations. The objective is to rapidly deliver implementable standard messages, in an incremental fashion, directly to emergency response agencies in the trenches, providing seamless communication and coordination supporting each particular process. The effort first addresses the most urgent needs and proceeds to subsequent message sets in a prioritized fashion. The goal is to incrementally develop and deliver standards. EDXL is intended as a suite of emergency data message types including resource queries and requests, situation status, message routing instructions and the like, needed in the context of cross-disciplinary, cross-jurisdictional communications related to emergency response. The priorities and requirements are created by the DM EDXL Standards Working Group (SWG) which is a formalized group of emergency response practitioners, technical experts, and industry. The draft DE specification was trialed by a number of EIC members starting in October, 2004. In November, 2004, EIC formally submitted the draft to the OASIS Emergency Management Technical Committee for standardization.

EDXL-RM (Resource Messaging)[edit]


EDXL-RM (Resource Message)[5] OASIS Standard, which describes a suite of standard messages for sharing data among information systems that coordinate requests for emergency equipment, supplies, and people.


The primary purpose of the Emergency Data Exchange Language Resource Messaging (EDXL-RM) Specification is to provide a set of standard formats for XML emergency response messages. These Resource Messages are specifically designed as payloads of Emergency Data Exchange Language Distribution Element- (EDXL-DE)-routed messages. Together EDXL-DE and EDXL-RM are intended to expedite all activities associated with resources needed to respond and adapt to emergency incidents. The Distribution Element may be thought of as a "container". It provides the information to route "payload" message sets (such as Alerts or Resource Messages), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs. The Resource Message is constrained to the set of Resource Message Types contained in this specification. The Resource Message is intended to be the payload or one of the payloads of the Distribution Element which contains it.


Disaster Management (DM) is a communications program in the Department of Homeland Security’s (DHS) Office for Interoperability and Compatibility (OIC) and managed by the Science and Technology (S&T) Directorate. The program was initiated as one of the President’s e-government initiatives. DM’s mission is to serve as the program within the Federal Government to help local, tribal, state, and federal public safety and emergency response agencies improve public safety response through more effective and efficient interoperable data sharing. The DHS DM program sponsors a Practitioner Steering Group (PSG). The DM 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-DM program. The group is composed of representatives of major emergency response associations, setting priorities and providing recommendations regarding messaging standards development as well as the other facets of the DM program. The PSG specified messaging standards-based systems interoperability as the top priority for the DHS Disaster Management program. The EDXL Resource Messaging Specification effort was identified as the top priority standard by this group following the EDXL-DE. The requirements and specification effort was initiated by this group in partnership with industry members of the Emergency Interoperability Consortium (EIC) in a Standards Working Group (SWG). That group developed a draft specification which was submitted to the OASIS Emergency Management Technical Committee to begin work on this EDXL-RM specification. The process remained the same as with the EDXL-DE specification with the exception that the Technical Committee requested that the initial candidate specification submitted by the expert group be recast as a formal Requirements Document according to a template that the Technical Committee provided to the expert group. The candidate specification was then resubmitted along with this requested requirements document.

EDXL-HAVE (Hospital Availability Exchange)[edit]


EDXL-HAVE (Hospital Availability Exchange)[6] OASIS Standard, which allows a hospital's status, services, and resources (including bed capacity, emergency department status, and available service coverage) to be communicated.


EDXL-HAVE specifies an XML document format that allows the communication of the status of a hospital, its services, and its resources. These include bed capacity and availability, emergency department status, available service coverage, and the status of a hospital’s facility and operations.


In a disaster or emergency situation, there is a need for hospitals to be able to communicate with each other, and with other members of the emergency response community. The ability to exchange data in regard to hospitals’ bed availability, status, services, and capacity enables both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiency and speed. In particular, it will allow emergency dispatchers and managers to make sound logistics decisions - where to route victims, which hospitals have the ability to provide the needed service. Many hospitals have expressed the need for, and indeed are currently using, commercial or self-developed information technology that allows them to publish this information to other hospitals in a region, as well as EOCs, 9-1-1 centers, and EMS responders via a Web-based tool. Systems that are available today do not record or present data in a standardized format, creating a serious barrier to data sharing between hospitals and emergency response groups. Without data standards, parties of various kinds are unable to view data from hospitals in a state or region that use a different system – unless a specialized interface is developed. Alternatively, such officials must get special passwords and toggle between web pages to get a full picture. Other local emergency responders are unable to get the data imported into the emergency IT tools they use (e.g. a 9-1-1 computer-aided dispatch system or an EOC consequence information management system). They too must get a pass word and go to the appropriate web page. This is very inefficient. A uniform data standard will allow different applications and systems to communicate seamlessly.

In 2013 the OASIS EM Technical Committee created a sub-committee to revise HAVE. HAVE version 2.0 is under development with draft schema and working documents in place. HAVE version 2.0 is aimed at addressing some shortfalls of the HAVE v1.0 (and the unofficial HAVE v1.1 that evolved informally) and to increase the depth of support for non-hospital facilities (e.g. urgent care clinics, long-term care facilities, temporary facilities).

Common Alerting Protocol[edit]

See (Common Alerting Protocol) OASIS standard preceding EDXL-DE that is often included in the EDXL family.

EDXL-SitRep (Situation Reporting)[edit]


EDXL-SitRep (Situation Reporting) completed the detailed practitioner requirements process in 2008 and was submitted by EIC and the U.S. Department of Homeland Security to OASIS to begin its standards process in March 2009.


EDXL-SitRep will provide a standard format for sharing general information across the disparate systems of any public or private organization and Emergency Support Function (ESF), about a situation, incident or event and the operational picture of current and required response. The purpose of EDXL-SitRep is to guide more effective preparation, response, management and recovery through seamless summary-level information-sharing before, during and after emergencies and disasters of any scale.

EDXL-TEP (Tracking of Emergency Patients)[edit]


EDXL-TEP is an XML messaging standard primarily for exchange of emergency patient and tracking information from patient encounter through hospital admission or release. TEP supports patient tracking across the EMS incident continuum of care, as well as evacuations from hospitals and day to day hospital patient transfers, providing real-time information to responders, emergency management, coordinating organizations and care facilities involved in incidents and the chain of care and transport. The TEP purpose embraces larger Phase II effort objectives for tracking everyone affected by and requiring emergency service or assistance as a result of a mass casualty incident, but is aimed at increased effectiveness of emergency medical services and management, patient tracking, and continued patient care preparedness during emergency care. TEP is driven by cross-profession practitioner needs (Practitioner Steering Group and expanded stakeholder groups), and led by the National Association of State EMS Officials (NASEMSO). It supports select goals of the HHS-Agency for Health and Research Quality (AHRQ) and gaps identified by the Health Information Technology Standards Panel (HITSP).

Government support[edit]

The U.S. Department of Homeland Security has increasingly embraced the EDXL suite of standards. Official grant guidance requires their use by grantees in information systems funded by the Department.

Related standards[edit]

Customer Information Quality[edit]

Customer Information Quality is another OASIS standard that is used in EDXL-RM and EDXL-HAVE. The CIQ set of specifications is for party, person, and organization information. The CIQ TC's objective in producing their specification was for "global" identification and was discovered to include information not applicable to the Emergency Management Domain. In light of this a profile was developed that maintained compliance with the original CIQ specification, but removed items not needed for EDXL.

GeoOASIS Where[edit]

The Geography Markup Language (GML) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. The EDXL Data Standards implement a profile of the GML standard called "GeoOASIS Where".

National Information Exchange Model[edit]

The National Information Exchange Model (NIEM) is an XML-based information exchange framework from the United States. NIEM represents a collaborative partnership of agencies and organizations across all levels of government (federal, state, tribal, and local) and with private industry. EDXL is considered to be NIEM compliant through a set of adapters that are contained within NIEM Core.

IEEE 1512[edit]

A related series of standards sponsored by the United States Department of Transportation and critical to emergency operations. The IEEE 1512 Family of standards are incident management and traffic incident related message sets. They provide incident management message sets common to traffic management, public safety, and hazardous materials incident response activities.[7]

See also[edit]


  1. ^ Take a Tour
  2. ^ OASIS Emergency Management TC | OASIS
  3. ^ Emergency Interoperability Consortium (EIC)
  4. ^ http://www.oasis-open.org/committees/download.php/17228/EDXL-DE_Spec_v1.0.pdf[bare URL PDF]
  5. ^ http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.pdf[bare URL PDF]
  6. ^ http://docs.oasis-open.org/emergency/edxl-have/pr03/emergency_edxl_have-1.0-spec-pr03.html
  7. ^ "IEEE Incident Management Working Group - Home". Archived from the original on 2009-04-19. Retrieved 2009-04-28.