· Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 1.0. Edited by Sukumar Dwarkanath. 22 December 2009. OASIS Standard Incorporating Approved Errata. http://docs.oasis-open.org/emergency/edxl-have/v1.0/errata/edxl-have-v1.0-os-errata-os.html.

This specification is related to:

· Emergency Data Exchange Language (EDXL) Distribution Element v1.0. Edited by Michelle Raymond, Sylvia Webb, and Patti Iles Aymond. 01 May 2006. OASIS Standard. http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf.

· 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. 22 December 2009. OASIS Standard incorporating Approved Errata. http://docs.oasis-open.org/emergency/edxl-rm/v1.0/errata/EDXL-RM-v1.0-OS-errata-os.html.

· Emergency Data Exchange Language Common Types v1.0. Edited by Werner Joerg, Rex Brooks, Jeff Waters, and Don McGarry. 13 January 2015. OASIS Committee Specification Draft. http://docs.oasis-open.org/emergency/edxl-ct/v1.0/edxl-ct-v1.0.html.

· Emergency Data Exchange Language Customer Information Quality v1.0. Edited by Werner Joerg and Jeff Waters. 13 January 2015. OASIS Committee Specification Draft. http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/edxl-ciq-v1.0.html.

Declared XML namespaces:

· urn:oasis:names:tc:emergency:edxl:have:2.0

Abstract:

EDXL-HAVE (HAVE) is an XML messaging standard primarily for exchange of information related to health facilities in the context of emergency management. HAVE supports sharing information about facility services, bed counts, operations, capacities, and resource needs so first responders, emergency managers, coordinating organizations, hospitals, care facilities, and the health community can provide each other with a coherent view of the health system.

Status:

This document was last revised or approved by the OASIS Emergency Management TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency#technical.

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/emergency/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/emergency/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[EDXL-HAVE]

Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 2.0. Edited by Darrell O’Donnell and Brian Wilkins. 13 January 2015. OASIS Committee Specification Draft 01 / Public Review Draft 01. http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd01/edxl-have-v2.0-csprd01.html. Latest version: http://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.html.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

Table of Contents

1 Introduction. 5

1.1 Terminology. 5

1.2 Normative References. 5

1.3 Non-Normative References. 6

1.4 Purpose. 6

1.5 History. 7

1.6 Structure of the EDXL Hospital Availability Exchange Specification. 7

2 Design Principles & Concepts (non-normative) 9

2.1 Requirements for Design. 9

2.2 Example Usage Scenarios. 10

2.2.1 Day-to-Day – Dialysis Patient: 10

2.2.2 First Responder – Responding with Critical Care. 10

2.2.3 Mass-Scale Vaccination Clinics. 10

2.2.4 Disaster Response: 10

3 EDXL HAVE. 11

3.1 HAVE Report Definition (non-normative) 11

3.2 Supporting Elements (non-normative) 11

3.2.1 Common Types. 11

3.2.2 Selecting Values from Lists. 12

3.2.3 ValueKeyType. 12

3.2.4 EDXL Extensions. 13

3.3 Element Reference Model (non-normative) 15

3.4 Distribution of EDXL-HAVE (non-normative) 16

3.5 HAVE Elements. 16

4 Data Dictionary. 17

5 Conformance. 18

Appendix A. Data Dictionary. 19

Appendix B. Acknowledgments. 87

Appendix C. Revision History. 89

1 Introduction

[All text is normative unless otherwise labeled]

1.1 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in Error! Reference source not found..

1.2 Normative References

[CAP-1.2] Common Alerting Protocol Version 1.2. 01 July 2010. OASIS Standard. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html.

[DATETIME] P. Biron and A. Malhotra, XML Schema Part 2: Datatypes Second Edition. 28 October 2004. W3C REC-xmlschema-2,, Sec 3.2.7, dateTime. http://www.w3.org/TR/xmlschema-2

[EDXL-CT] Joerg, W. Committee Specification Draft Emergency Data Exchange Language Common Types. November 2011. OASIS. http://docs.oasis-open.org/emergency/edxl-ct/v1.0/csd01/

[EDXL-DE] EDXL Distribution Element (DE) Standard v1.0. March 2006. OASIS. http://www.oasis-open.org/specs/index.php#edxlde-v1.0

[EDXL-GSF] Joerg, W. Committee Specification Draft Emergency Data Exchange Language GML Simple Features. September 2011. OASIS. http://docs.oasis-open.org/emergency/edxl-gsf/v1.0/csd01/

[NAMESPACES] T. Bray et al, Namespaces in XML 1.0 (Second Edition). January 1999. W3C REC-xml-names-19990114. http://www.w3.org/TR/xml-names/

[OASIS CIQ] Customer Information Quality (CIQ) Specifications Version 3.0, Name (xNL), Address (xAL), and Party (xPIL). June 15, 2007. OASIS. http://docs.oasis-open.org/ciq/v3.0/specs/

[OGC 07-36r1] Geography Markup Language (GML) Implementation Specification Version 3.2.1. 2007. Open Geospatial Consortium. http://portal.opengeospatial.org/files/?artifact_id=20509

[OGC Schemas] GML 3.2.1 schemas. 2007. Open Geospatial Consortium. http://schemas.opengis.net/gml/3.2.1/

[OGC 10-100r3] Geography Markup Language (GML) simple features profile (with Corrigendum) (2.0). 2010. http://portal.opengeospatial.org/files/?artifact_id=42729

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

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels. March 1997. IETF RFC 2119. http://www.ietf.org/rfc/rfc2119.txt

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

[WGS 84] Department of Defense World Geodetic System. 1984. National Geospatial Intelligence Agency. http://earth-info.nga.mil/GandG/wgs84/index.html

[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Fourth Edition). February 2004. W3C REC-XML-20040204. http://www.w3.org/TR/REC-xml/

1.3 Non-Normative References

[AHIC-BIODATA] BioSurvellience Data Elements. American Health Information Community (AHIC), BioSurvellience Data Working Group. http://www.hhs.gov/healthit/ahic/bio_main.html

[EDXL-EXT] EDXL Extension, OASIS. https://tools.oasis-open.org/version-control/browse/wsvn/emergency/HAVE/rim/edxl-ext-v1.0.xsd

[GJXDM] Global Justice XML Data Model (GJXDM) Data Dictionary. Global, Office of Justice Programs. http://it.ojp.gov/topic.jsp?topic_id=43

[GML-BESTPRAC] Best Practices: A GML Profile for use in OASIS EM Standards - EDXL-RM, EDXL-DE, HAVE, and CAP DRAFT. Open Geospatial Consortium. http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20785/Best%20Practices%20-%20a%20GML%20Profile.doc

[HAVBED-DATA] Hospital Bed Availability (HAvBED) Project – Definitions and Data Elements: AHRQ Releases Standardized Hospital Bed Definitions. Agency for Healthcare Research and Quality (AHRQ): http://www.ahrq.gov/research/havbed/definitions.htm

[HAVBED2-REP] HAvBED2 Hospital Available Beds for Emergencies and Disasters. A Sustainable Bed Availability Reporting System. Final report. AHRQ Publication No. 09-0058-EF. April 2009. AHRQ. http://archive.ahrq.gov/prep/havbed2/havbed2.pdf

[HAVE-REQSUP] EDXL HAVE Requirements Supplement. January 2006. OASIS. http://www.oasis-open.org/committees/download.php/16400/

[HAVE-SRS] EDXL HAVE Standard Requirements Specification. January 2006. OASIS. http://www.oasis-open.org/committees/download.php/16399/

[HL7] Health Level Seven International. - http://www.hl7.org/.

[RM-DATAREQ] EDXL Resource Messaging (RM) Draft Requirements Specification. OASIS. http://www.oasis-open.org/committees/download.php/14310/

[VHHA-TERM] Statewide Hospital Status Information System Terminology and Data Collection Elements. Virginia Hospital & Healthcare Association (VHHA). http://www.oasis-open.org/committees/download.php/18019

1.4 Purpose

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

The current roster of published EDXL Standards includes:

The Common Alerting Protocol v1.2 specification (EDXL-CAP), with various dedicated profiles
The Distribution Element specification v2.0 (EDXL-DE)
The Hospital AVailability Exchange specification v1.0 (EDXL-HAVE)
The Resource Messaging specification v1.0 (EDXL-RM)
The Situation Reporting specification v1.0 (EDXL-SitRep)

The primary purpose of EDXL-HAVE is to provide an XML-based reporting format that allows information to be shared about a set of health facilities including the communication of the status of a health facility, its services, and its resources. These include bed capacity and availability, emergency department status, staffing levels, available service coverage, and the status of a health facilities operations and resources.

The primary audience for EDXL-HAVE is the broad community that interacts with health facilities and it is intended to be used as a tool to automate information flow in and out of the health network. It is not intended to be a tool used for internal administration of health facilities as other standards organizations (e.g. Health System Level Seven International – www.hl7.org) already handle this domain.

1.5 History

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.

The Hospital Availability Exchange standard was created to make sharing information about the state of hospitals for day-to-day and crisis use. Initially it was focused purely on hospitals but it has been extended to handle sharing information about the broader health network, including long-term care facilities, urgent care clinics, and temporary aid centres.

HAVE 1.0 was released on 22DEC2009. Since the release of HAVE 1.0 there have been multiple operational uses of HAVE, including after the 2010 Haiti Earthquake. In many of the operational uses there were modified schema used to add services that were not in HAVE 1.0 and to convey other aspects of the data and to handle the sharing of information about non-hospital facilities (e.g. clinics, temporary locations). The use of the HAVE 1.0 standard was encouraging but the shortfalls needed to be addressed. To that end, in 2010 the OASIS EM-TC voted to re-open the HAVE standard with the goal of creating a HAVE 2.0 standard.

1.6 Structure of the EDXL Hospital Availability Exchange Specification

The EDXL-HAVE 2.0 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-HAVE XML Schema is provided separately. The overall structure of the EDXL-HAVE 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-HAVE standard is defined in the following sections:

Section 2 summarizes the design principles of the standard and shows several usage scenarios;
Section 3 provides and informal overview of EDXL-HAVE. In particular:

Section 3.1 presents an extensive definition of a HAVE report;
Section 3.2 describes essential supporting elements in the EDXL Common Types collection, including the use of EDXL Extensions;
Section 3.3 presents the Element Reference Model (ERM) which shows the abstract structural relationships of the main components of EDXL-HAVE;
Section 3.4 discusses how the distribution requirements for EDXL-HAVE messages may be met through several mechanisms, including EDXL-Distribution Element (DE) and as general data payloads;
Section 3.5 presents a summary of the elements that make up a HAVE message.

Section 4 The Data Dictionary formally defines each element contained in the EDXL-HAVE standard message.
Section 5 provides conformance information.

These sections together define the message structure, message element definitions, optionality and

cardinality.

2 Design Principles & Concepts (non-normative)

Below are some of the guiding principles behind the development of EDXL-HAVE:

Support day-to-day and crisis use of the standard.
Facilitate sharing of information amongst the general public, all levels of government, first nation/tribal, international, and non-governmental organizations.
Provide a simple information report that allows first responders, emergency managers, community leaders, politicians, and other stakeholders to get a quick glimpse of the state of the health network in a community.
Provide a non-invasive way for a health facility to keep the communities that they serve abreast of developments that impact their ability to provide care.
Be respectful of the boundaries of internal health facility information and the information that is relevant externally.
Separation of EDXL-HAVE reports from being tied to a particular method of delivery.
Use and reuse of data, content, and models developed by other initiatives that align with EDXL-HAVE.
Provide a baseline set of services, operations, and resources to allow health facilities to start using HAVE quickly, while allowing for controlled extension where warranted.

2.1 Requirements for Design

The OASIS EM-TC tasked the EDXL-HAVE Sub-committee to review HAVE 1.0 and propose Errata, Minor, and Major versions. The initial tasking provided the following guidance:

Figure 1 - EM EDXL-HAVE SC Scope

2.2 Example Usage Scenarios

The following scenarios illustrate how EDXL-HAVE 2.0 can be used in the field.

2.2.1 Day-to-Day – Dialysis Patient:

On a routine pickup a social worker picks up an elderly patient that needs routine maintenance. Normally the dialysis is performed at the closest facility, but the social worker knows that the small facility’s dialysis unit is not operating due to an equipment failure. A quick query to view the local health facilities presents several within a 20-minute drive, so the social worker places a call and coordinates with one of the alternate facilities.

2.2.2 First Responder – Responding with Critical Care

As the result of a multi-unit residential fire, ambulances are dispatched and the Incident Commander indicates that there are 2 critical and 3 serious burn victims. The nearest hospital can only take in 2 burn victims normally, but the current state of the burn unit is not known. By examining the state of the local facilities, officials can coordinate which victims are to be taken to the surrounding health facilities.

2.2.3 Mass-Scale Vaccination Clinics

Under pandemic conditions a community is implementing a vaccination program with the hospitals, urgent care clinics, private clinics, and temporary clinics providing vaccinations. The public, key officials, and the media can have immediate visibility into the wait times and service availability at each of the vaccination sites. EDXL-HAVE provides the ability to display service availability for each facility, referenced on a map, by colour code and to provide an indication of wait times if they are available.

2.2.4 Disaster Response:

Following a major earthquake in the developing world, NGOs, various government responders, and local officials (and non-officials) establish temporary health-care facilities to meet the urgent and non-urgent health needs of those injured or killed by the earthquake and ensuing issues. Coordination of multiple dimensions are critical: what services are available, what is the capacity of the facilities, what resources they are missing or can share, where are the facilities located, who are the official points of contacts, what agency is running the facility, what are the hours operation, etc.

As the event unfolds there is a Cholera outbreak due to damaged sanitation. There is a clear need identified to track 2 particular services (e.g. Cholera Vaccination and Cholera Treatment) that were too specific to be part of the default HAVE 2.0 services taxonomy. After a meeting of the coordinating agencies, the data being shared is extended to include Cholera Vaccination and Cholera Treatment services, including the standard metrics (capacity, colour code for status, etc.)

3 EDXL HAVE

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 HAVE Report Definition (non-normative)

The HAVE Report is a single EDXL message that is intended to provide sharing of the services, operations, and capacities of health facilities. Health facilities in HAVE include hospitals, urgent care clinics, temporary facilities, and other facilities that may provide health services for a community.

Typical actors:

Senders – hospital administrators, hospital networks, health providers, NGOs, clinic administrators, and emergency medical services, etc.
Recipients – first responders, dispatch operators, emergency managers, automated systems, etc.

3.2 Supporting Elements (non-normative)

3.2.1 Common Types

Supporting Element Types borrow re-usable elements from the EDXL Common Types (ct:) that apply to and support multiple areas of the HAVE 2.0 reports, such as Location. For instance incidentLocation relies on ct:EDXLLocationType, which consists of either EDXLGeoLocation for geographical information or EDXLGeoPoliticalLocation for geopolitical information. EDXLGeoLocation is of type edxl-gsf:EDXLGeoLocationType and EDXLGeoPoliticalLocation is of type ct:EDXLGeoPoliticalLocationType. This latter type consists of either a GeoCode (of type ct:ValueListType) or an Address (of type edxl-ciq:xAL:AddressType).

The following elements are used in this specification and can be found at the locations cited in the normative references in Section 1.2 of this document.

Supporting Element/Type	Defined In
ct:EDXLDateTimeType	EDXL-CT (Simple Types)
ct:EDXLStringType	EDXL-CT (Simple Types)
ct:ValueListURIType	EDXL-CT (Simple Types)
ct:ValueType	EDXL-CT (Simple Types)
ct:ValueListType	EDXL-CT (Complex Types)
ct:ValueKeyType	EDXL-CT (Complex Types)
ct:EDXLGeoPoliticalLocationType	EDXL-CT (Complex Types)
ct:EDXLLocationType	EDXL-CT (Complex Types)
gsf:EDXLGeoLocationType	EDXL-GSF
ct:ValueListURI	EDXL-CT (Top Level Elements)
xal:addressType	EDXL-CIQ

Some elements of the common type “ct:EDXLStringType” are denoted as [token] in the accompanying XML per the following reference:

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

The definition for token as found in the OASIS common types is: “The value space of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces.”

The implication is that the XML parser will change string entries to remove carriage returns, line feeds, tab characters, leading or trailing spaces, and internal sequences of two or more spaces.

3.2.2 Selecting Values from Lists

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 externalCode alternateCodeValue, 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

3.2.3 ValueKeyType

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 a resource need of a facility:

valueListURI = https://www.medwish.org/give/medical-supplies/
value = Bandages

which stands for

<ct:ValueListURI>https://www.medwish.org/give/medical-supplies/</ct:ValueListURI>

<ct:Value>Bandages</ct:Value>

</resourceKind>

Following the approach in ValueList, we'd point ValueListURI to some other list to make a different selection of eye colors available.

3.2.4 EDXL Extensions

HAVE 2.0 supports supplemental inclusion of community-defined sets of name/value pairs, referred to here as “Community Extensions” or simply “Extensions” for short. For example, the HAVE Status element contains a stability field, which indicates if the status is stable, improving, or deteriorating. The “Extension” concept would allow a sender to augment this information with a qualifier, such as “rapidly” or “slowing”, providing finer grain detail on the situation. 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. The Community Extensions that are most successful can be incorporated formally into future standards.

Typical needs are:

Standard augmentation: community adds new information that is associated with the EDXL standard. Examples: adding HL7 translation information to the HAVE payload.
List augmentation: community adds new values (enumerations) to the default set of values in the standard. Example: adding community-specific information to the ServiceType element.

In HAVE 2.0, “Extensions” are used under the following elements:

ServiceType
ResourceInformationType
OperationType
OffloadInfoType
TraumaCenterLevelType

The schema for Extension is defined as

<xs:element name="extension">

<xs:complexType>

<xs:sequence>

<xs:element name="community" type="xs:anyURI" />

<xs:element name="id" type="xs:anyURI /">

<xs:element name="parameter" type="ext:ParameterType" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

and its application to the XML description of an extension would be:

<extension>

<community>communityURI</community>

<id>idURI</id>

<parameter>

<nameURI>nameURI</nameURI>

<value>some value</value>

</parameter>

</extension>

This example uses a qualify for status stability for a service:

community = facility:service:status:refined
id = extension:1
parameter-nameURI = have:service:status
parameter-value = Rapidly

which stands for

<community>facility:service:status:refined</community>

<id>extension:1</id>

<nameURI>have:service:status</nameURI>

<value>Rapidly</value>

</parameter>

</extension>

3.4 Distribution of EDXL-HAVE (non-normative)

HAVE messages are intended to be payloads of various messaging and/or delivery systems. Messaging systems such as EDXL-DE can treat a HAVE message as a payload. Similarly, non-message-based systems (e.g. RESTful web service) can deliver a HAVE message just as easily. An individual facility may provide an up-to-date report via a web service. An aggregator could poll the facilities that are of interest for a particular reason, or in a Publish-Subscribe scenario, subscribe to the facilities of interest.

3.5 HAVE Elements

A HAVE message consists of an organization that uniquely identifies the organization that is responsible for the reporting facilities, a reporting period (reportingPeriod – optional) that identifies reporting period applicable for this HAVE report, and a group of elements (facility – required) that uniquely identifies and describes the facility’s status including

· facility name and location,

· overall facility status, ..

· services, ..

· operations, ..

· resources, ..

· staffing, ..

· and emergency department.

These elements are detailed further in the Element Reference Model (Section 3.3) and in the Data Dictionary (Section 4).

4 Data Dictionary

Appendix A contains a computer-generated PDF that is generated directly from the XML Schema document.

5 Conformance

An XML 1.0 element is a conforming EDXL-HAVE-v2.0 Message if and only if:

a) it meets the general requirements specified in Section 4;

b) if its namespace name is "urn:oasis:names:tc:emergency:edxl:have:2.0", and the element is valid according to the schema located at http://docs.oasis-open.org/emergency/edxl-have-v2.0/edxl-have-v2.0.xsd

c) if its namespace name is "urn:oasis:names:tc:emergency:edxl:have:2.0", 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 4 corresponding to the element’s name.

Note: only messages that fully comply with the EDXL-HAVE 2.0 specification and that are complete and schematically valid may be referred to as a “EDXL-HAVE 2.0 Message”.

Appendix A. Data Dictionary

The following PDF is generated from the formal EDXL-HAVE 2.0 Schema.

The PDF file is available in the “schemas” directory listed in the “Additional artifacts” section on the title page.

Appendix B. Acknowledgments

The HAVE Subcommittee is Chaired by Darrell O’Donnell who has worked tirelessly and through holidays to bring this specification to the EM-TC for approval and advancement to a Standard under the close guidance of the OASIS process. He has been ably assisted by Brian Wilkins who has also participated intently to bring this work to conclusion. The following individuals have participated in the subcommittee creating this specification and are gratefully acknowledged:

Patti Aymond, IEM

Rex Brooks, Individual

Lizzie DeYoung, MITRE

Tom Ferrentino, Individual

Tim Grapes, Individual

Elysa Jones, Individual

Emily Laughren, MITRE

Donald McGarry, MITRE

Mark Prutsalis, Sahana Software Foundation

Rob Torchon, Individual

Brian Wilkins, MITRE

We are also grateful for the EM-TC participants for their oversight and guidance:

Doug Allport, Canadian Public Safety Operations Organization

David Askov, Pacific Disaster Center

Patti Aymond, IEM

Art Botterell, Individual

Rex Brooks, Individual

Robert Bunge, NOAA's National Weather Service

Yu Chen, Google Inc.

Eliot Christian, Individual

Toby Considine, University of North Carolina at Chapel Hill

William Cox, Individual

CAPAU Custodian, Australian Government Attorney-General's Department

Lizzie DeYoung, MITRE Corporation

Thomas Ferrentino, Individual

Mike Gerber, NOAA's National Weather Service

Timothy Grapes, Individual

Robert Gustafson, MITRE Corporation

Steve Hakusa, Google Inc.

Gary Ham, Individual

Werner Joerg, Individual

Elysa Jones, Individual

Michael Kristan, MITRE Corporation

Ram Kumar, Individual

Dominic König, Sahana Software Foundation

Emily Laughren, MITRE Corporation

Mark Lucero, US Department of Homeland Security

Donald McGarry, MITRE Corporation

Thomas Merkle, US Department of Homeland Security

Darrell O'Donnell, Individual

Camille Osterloh, Individual

Norm Paulsen, Environment Canada

Glenn Pearson, Sahana Software Foundation

Efraim Petel, AtHoc, Inc.

Tomer Petel, AtHoc, Inc.

Mark Prutsalis, Sahana Software Foundation

Carl Reed, Open Geospatial Consortium, Inc. (OGC)

Aviv Siegel, AtHoc, Inc.

Steve Streetman, US Department of Homeland Security

Robert Torchon, Individual

Richard Vandame, US Department of Homeland Security

Nuwan Waidyanatha, Sahana Software Foundation

Jeff Waters, US Department of Defense (DoD)

Jacob Westfall, Individual

Herbert White, NOAA's National Weather Service

Brian Wilkins, MITRE Corporation

Ka-Ping Yee, Google Inc.

Appendix C. Revision History

Revision	Date	Editor	Changes Made
WD02	23DEC2014	Darrell O’Donnell	Preparation for submission to OASIS EM-TC
WD02	13JAN2015	Darrell O’Donnell	Updates to reflect RIM (CT, CIQ, and GSF) working drafts.
CSD01	13JAN2014	Darrell O’Donnell	Updates to reflect EM TC Committee Specification Draft