The EDXL Distribution Element (DE) specification describes a standard message distribution framework for data sharing among emergency information systems using the XML-based Emergency Data Exchange Language (EDXL). This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding.

Declared XML Namespace(s):

urn:oasis:names:tc:emergency:EDXL:HAVE:1.0

Abstract:

This Hospital AVailability Exchange (HAVE) describes a standard message for data sharing among emergency information systems using the XML-based Emergency Data Exchange Language (EDXL). This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding.

Status:

This document was last revised or approved by the Emergency Management on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at 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 Technical Committee web page (www.oasis-open.org/committees/emergency/ipr.php.

The non-normative errata page, if any, for this specification is located at www.oasis-open.org/committees/emergency/.

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 names "OASIS", “CAP”, “EDXL”, and “EDXL-HAVE” are trademarks 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 http://www.oasis-open.org/who/trademark.php for above guidance.

TABLE OF CONTENTS

1.3 NORMATIVE REFERENCES. 7

1.4 NON-NORMATIVE REFERENCES. 8

2 DESIGN PRINCIPLES AND CONCEPTS. 10

2.1 DESIGN PHILOSOPHY. 10

2.2 REQUIREMENTS FOR DESIGN. 10

2.3 EXAMPLE USAGE SCENARIOS. 10

3 EDXL HOSPITAL AVAILABILITY EXCHANGE (HAVE) ELEMENT STRUCTURE. 11

3.1 DOCUMENT OBJECT MODEL (non-normative) 11

3.2 DATA DICTIONARY. 12

3.2.1 HOSPITAL STATUS. 12

3.2.2 ORGANIZATION. 13

3.2.3 EMERGENCY DEPARTMENT STATUS. 16

3.2.4 HOSPITAL BED CAPACITY STATUS. 23

3.2.5 SERVICE COVERAGE STATUS. 30

3.2.6 HOSPITAL FACILITY STATUS. 52

3.2.7 HOSPITAL RESOURCES STATUS. 59

3.2.8 SUPPORTING ELEMENTS AND TYPES (Normative) 61

4 CONFORMANCE. 71

4.1 CONFORMANCE TARGETS. 71

4.2 CONFORMANCE AS AN EDXL-HAVE REPORT. 71

4.3 CONFORMANCE AS AN EDXL-HAVE REPORT PRODUCER. 71

A. EDXL-HAVE EXAMPLE (non-normative) 73

B. Bed Types and Capacity - Definitions (non-normative) 76

C. OASIS Customer Information Quality (CIQ) (non-normative) 78

D. ACKNOWLEDGEMENTS. 79

E. REVISION HISTORY. 81

1 INTRODUCTION

1.1 OVERVIEW

1.1.1 PURPOSE

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.

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

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.

1.1.3 STRUCTURE

The most important XML elements specified in this standard as part of the EDXL-HAVE document format are the following:

This is the overall top level container element for all the <Hospital> elements that may be present.

This is the top level container element for each reporting organization. Each <Hospital> element has the following set of sub-elements.

The <Organization> element provides basic information about the name and location of the organization about which the status and availability is being reported.

The <EmergencyDepartmentStatus> element provides information on the ability of the emergency department of the organization to treat patients.

The <HospitalBedCapacityStatus> element provides information on the status and availability of the bed capacity of the organization. The bed capacity information for specific bed types can be reported.

The <ServiceCoverageStatus> element provides information on the availability of specialty service coverage. This includes both the necessary staff and facilities. Some of the services capabilities are broken down into subtypes. This is to allow organizations to designate subtypes, if available. Others can report just the higher level specialties.

The <HospitalFacilityStatus> element provides information on the status of the facility. This includes information on the EOC and the capacity of the facility.

The <HospitalResourcesStatus> element provides information on the status of operations and resources of the organization.

The <LastUpdateTime> element provides information on the time that the information was last updated.

This standard references element and type definitions specified in the following standards and profiles:

· [OASIS CIQ] – The CIQ standard is used for defining the name, address and location information in EDXL HAVE.

· [geo-oasis] – OASIS GML Profile – This profile is used to define the geo-location elements in EDXL HAVE.

1.2 TERMINOLOGY

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

AHA	American Hospital Association
CIQ	Customer Information Quality
EDXL	Emergency Data Exchange Language
EOC	Emergency Operations Center
EOP	Emergency Operations Plan
EMS	Emergency Medical Services
GJXDM	Global Justice XML Data Model
GML	Geographic Markup Language
HAvBED	Hospital Bed Availability (HAvBED) Project
ICU	Intensive Care Unit
NIEM	National Information Exchange Model
OBGYN	Obstetrics and Gynecology

1.3 NORMATIVE REFERENCES

[RFC2119]

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

[RFC3066]

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

[WGS 84]

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

[XML 1.0]

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

[namespaces]

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

[dateTime]

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

[OGC 03-105r1]

OpenGIS Geography Markup Language (GML) Implementation Specification, http://portal.opengeospatial.org/files/?artifact_id=4700, Version 3.1.1, 2003

[OGC CRS]

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

[OGC 04-092r4]

Open Geospatial Consortium, GML 3.1.1 schemas, http://schemas.opengis.net/gml/3.1.1/, 2004

[OASIS CIQ]

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

1.4 NON-NORMATIVE REFERENCES

[edxl-have SRS]

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

[edxl-have ReqSupp]

EDXL HAVE Requirements Supplement, http://www.oasis-open.org/committees/download.php/16400/, January 2006.

[HAvBED Report]

Hospital Bed Availability Project, National Hospital Available Beds for Emergencies and Disasters (HAvBED) System. Final report and appendixes. AHRQ Publication No. 05-0103, December 2005. Agency for Healthcare Research and Quality, Rockville, MD. http://www.ahrq.gov/research/havbed/

[HAvBED DataDef]

Hospital Bed Availability (HAvBED) Project – Definitions and Data Elements, Agency for Healthcare Research and Quality (AHRQ): “AHRQ Releases Standardized Hospital Bed Definitions” http://www.ahrq.gov/research/havbed/definitions.htm

[VHHA Terminology]

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

[GJXDM]

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

[edxl-de]

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

[edxl-rm]

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

[AHIC BioDataElements]

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

[OASIS GML Best Practices]

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

2 DESIGN PRINCIPLES AND CONCEPTS

2.1 DESIGN PHILOSOPHY

The principles that guided the design of the HAVE include:

Interoperability - The HAVE message should provide an interoperable mechanism to exchange healthcare organization information among different domains and among multiple systems
Multi-Use Format – The HAVE message must be designed such that it can be used in everyday events, during mass disasters, and for incident preparedness.
Flexibility – The design structure must be flexible such that it could be used by a broad range of applications and systems to report status and availability information

2.2 REQUIREMENTS FOR DESIGN

This standard was designed taking the following requirements into account:

1. Allow medical and healthcare organizations to communicate their status and availability information.

2. Be designed to allow its use by a wide variety of medical and healthcare organizations (including hospitals and nursing homes), along with other emergency response organizations (such as emergency management centers, public safety answering points, and dispatch centers).

3. Be able to be used as a payload or content element with the EDXL Distribution Element.

4. Allow the communication of status information of one or more organizations in a single exchange.

5. Allow the communication of the organization’s status and availability information with regard to its facilities, operations, services, and resources.

6. Be designed to allow its use in normal operations, day-to-day emergencies and mass disasters.

2.3 EXAMPLE USAGE SCENARIOS

Use of HAVE during a mass disaster

A major disaster has occurred in a heavily populated city. A number of casualties are reported, and the Incident Commander (IC) needs to obtain a common operational picture on the status of the hospitals in the region, including the resources they can offer. The IC sends a message to the regional hospitals for an update on their status and bed availability information.

Hospitals receive this request, and use their respective systems to send HAVE messages. These messages contain the status of each hospital’s emergency department, bed availability information, and the hospital’s operations and facilities. These are accepted into the IC’s Consequence Incident Management System (CIMS) tool, and similar tools used by other emergency response agencies (e.g. Computer-Aided Dispatch systems used in public safety answering points).

Use of HAVE during an everyday emergency

A car crash has occurred in a rural area resulting in two badly burned victims, according to on-scene public safety personnel. Before the EMS staff reaches the scene, EMS dispatch sends a request to nearby hospitals for a status of available burn services and burn beds.

A few hospitals respond to the request, and use the service coverage element in the HAVE message to specify the burn coverage available at their facilities. They in turn are able to assemble their burn teams in order to ensure that there is no delay in treatment. Based on the acquired information, the victims are taken to the nearest hospital with the required services.

3 EDXL HOSPITAL AVAILABILITY EXCHANGE (HAVE) ELEMENT STRUCTURE

3.1 DOCUMENT OBJECT MODEL (NON-NORMATIVE)

Figure 1: EDXL-HAVE DOM

3.2 DATA DICTIONARY

The following section provides additional clarification on interpreting the various fields identified in the data dictionary:

The EDXL-HAVE schema is normative and is located here - http://docs.oasis-open.org/emergency/edxl-have/v1.0/edxl-have.xsd

The Data Dictionary is used to provide additional clarifications, except for the following entries which are normative:

· Element

· Usage

· Constraints

In the Data Dictionary, unless otherwise specified explicitly, the following entries are non-normative:

· Type

· Note: In some cases, it refers to the complex types and these are normative. These exceptions are identified in the Data Dictionary, where applicable.

· Definition:

· Used In

· Comments

· Sub-elements

Note:

This standard does not specify any transport, distribution, or routing mechanism for an EDXL-HAVE document. One way of using this standard is by including one or more EDXL-HAVE documents in the payload of an EDXL-DE message.

3.2.1 HOSPITAL STATUS

Element	<have:HospitalStatus>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once, top level container.
Definition	The top level container element for reporting status of any number of hospitals.
Constraints	<HospitalStatus> MUST contain one or more <Hospital> elements.
Sub-elements	· Hospital
Used In	Top Level Element

Element	<have:Hospital>
Type	XML Structure
Usage	REQUIRED, May Use Multiple; Must be used for each reporting hospital status.
Definition	The container element for reporting status of a hospital.
Sub-elements	· Organization · EmergencyDepartmentStatus · HospitalBedCapacityStatus · ServiceCoverageStatus · HospitalFacilityStatus · HospitalResourcesStatus · LastUpdateTime
Used In	HospitalStatus

3.2.2 ORGANIZATION

Note on CIQ

EDXL-HAVE uses the Customer Information Quality (CIQ) profile for defining the name, address and other details of the Organization.

This standard references certain XML elements and types, as specified in [OASIS CIQ], and provides recommendations on their use inside an EDXL-HAVE document. Those recommendations limit the choices available to an implementation of this standard in order to maximize interoperability.

The EDXL HAVE data dictionary only provides a high level overview of the CIQ elements that are used in this standard. It is highly recommended to refer to the OASIS CIQ Version 3.0 Specifications for implementation details and examples.

While EDXL-HAVE uses Organization, CIQ uses Organisation. In [OASIS CIQ] the spelling “organisation” is used whenever this word occurs in the name of an element specified in that standard. In contrast, the spelling “organization” is used in this standard whenever this word occurs in the name of an element specified in this standard. Obviously, when an element specified in [OASIS CIQ] is referenced within this standard, the original spelling (with an “s”) is used for its name.

While CIQ provides a capability to specify geo-location by LocationByCoordinates and GeoRSS, EDXL-HAVE specifies the use of the OASIS GML profile – geo-oasis.

Please see Appendix C for a brief note on the OASIS CIQ Standard.

Note on Organization

The term “organization” is used in this standard to refer to a hospital, a nursing care center, a trauma center, or any other organization whose resource availability can be usefully represented in an EDXL-HAVE document.

Element	<have:Organization>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once.
Definition	The container element for Organization information elements.
Comments	1. The generic element Organization refers to the entity, the status and availability of which is being reflected in the status message.
Sub-elements	· OrganizationInformation · OrganizationGeoLocation
Used In	HospitalStatus/Hospital

Element	<have:OrganizationInformation>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once, top level container
Definition	The container element for Organization Information elements.
Sub-elements	· OrganisationName · OrganisationInfo · Addresses · ContactNumbers · CommentText
Used In	HospitalStatus/Hospital/Organization

Element	<have:OrganizationGeoLocation>
Type	geo-oasis:WhereType
Usage	OPTIONAL
Definition	The container element for specifying the geo-coded address.
Constraints	1. The geo-location MUST match the address specified in <OrganizationInformation>
Comments	1. This specification uses the OASIS GML profile for specifying the geo-location. 2. The type "geo-oasis:WhereType" is specified in [geo-oasis] as having a complex content that is a choice between five elements (See 3.2.8.4). 3. It is RECOMMENDED that the element <gml:Point> be used in an EDXL-HAVE document in preference to the other four elements. Note: See Appendix D
Used In	HospitalStatus/Hospital/Organization

3.2.3 EMERGENCY DEPARTMENT STATUS

Element	<have:EmergencyDepartmentStatus>
Type	XML Structure
Usage	OPTIONAL
Definition	The container of all of the elements related to the emergency department status.
Comments	1. It describes the ability of this emergency department to treat patients.
Sub-elements	· EMSTraffic · EMSCapacity · EMSCensus · EMSAmbulanceStatus · EMSAirTransportStatus · CommentText
Used In	HospitalStatus/Hospital

Element	<have:EMSTraffic>
Type	XML Structure
Usage	OPTIONAL
Definition	The container of all of the elements related to the status of operations of EMS traffic.
Comments	1. It defines the ability of this emergency department to receive patients via emergency medical services.
Sub-elements	· EMSTrafficStatus · EMSTrafficReason · CommentText
Used In	HospitalStatus/Hospital/EmergencyDepartmentStatus

Element	<have:EMSTrafficStatus>
Type	xsd:string with restrictions
Usage	OPTIONAL
Definition	Identifies the status of EMS traffic operations.
Comments	Value must be one of: 1. Normal - Accepting all EMS traffic 2. Advisory - Experiencing specific resource limitations which may affect transport of some EMS traffic. 3. Closed - Requesting re-route of EMS traffic to other facilities. 4. NotApplicable - Not Applicable. This hospital does not have an emergency department.
Used In	HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSTraffic

Element	<have:EMSTrafficReason>
Type	xsd:string with restrictions
Usage	OPTIONAL
Definition	It is used to report the contributing factor to the status specified in <EMSTrafficStatus>.
Used In	HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSTraffic

Element	<have:EMSCapacity>
Type	TriageCount
Usage	OPTIONAL
Definition	The number of each triage patient type the hospital can accept.
Comments	1. Please refer to Sec. 3.2.8.5
Used In	HospitalStatus/Hospital/EmergencyDepartmentStatus

Element	<have:EMSCensus>
Type	TriageCount
Usage	OPTIONAL
Definition	The number of each triage patient type the overall hospital currently has.
Comments	1. Please refer to Sec 3.2.8.5
Used In	HospitalStatus/Hospital/EmergencyDepartmentStatus

&nb