EDXL-HAVE

OASIS logo

Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) v1.0

Public Review Draft 02, 02 November 2006

Artifact Identifier:

emergency-edxl-have-1.0-spec-pr02

Location:

Current: docs.oasis-open.org/emergency/EDXL-HAVE/V1.0

This Version: docs.oasis-open.org/emergency/EDXL-HAVE/V1.0/edxl_have-1.0-spec-pr02

Previous Version:docs.oasis-open.org/emergency/EDXL-HAVE/V1.0/edxl_have-1.0-spec-pr-01-rev01

Artifact Type:

Specification

Technical Committee:

OASIS Emergency Management TC

Chair(s):

Elysa Jones, Warning Systems, Inc., <ejones@warningsystems.com>

Editor(s):

Sukumar Dwarkanath, Associate Member - <sdwarkanath@comcare.org>

Subject/Keywords

Hospital bed capacity, hospital status, emergency department report, hospital service coverage status, facility status, medical organization status and bed capacity, healthcare organization status, availability, hospital resources, healthcare organization resources; bio surveillance; resource utilization.

Related Work:

This specification is related to:

EDXL-DE v1.0 - http://www.oasis-open.org/committees/emergency

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.

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 approved as a public review draft by the Emergency Management TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this

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

Table of Contents

1.0 Introduction

1.1 OVERVIEW

1.1.1 PURPOSE

1.1.2 HISTORY

1.1.3 STRUCTURE

1.2 TERMINOLOGY

1.3 NORMATIVE REFERENCES

1.4 NON-NORMATIVE REFERENCES

2.0 DESIGN PRINCIPLES AND CONCEPTS

2.1 DESIGN PHILOSOPHY

2.2 REQUIREMENTS FOR DESIGN

2.3 EXAMPLE USAGE SCENARIOS

3.0 EDXL HOSPITAL AVAILABILITY EXCHANGE (HAVE) ELEMENT STRUCTURE (normative)

3.1 DOCUMENT OBJECT MODEL

3.2 DATA DICTIONARY

3.2.1 ORGANIZATION INFORMATION

3.2.2 EMERGENCY DEPARTMENT STATUS

3.2.3 HOSPITAL BED CAPACITY STATUS

3.2.4 SERVICE COVERAGE STATUS

3.2.5 HOSPITAL FACILITY STATUS

3.2.6 HOSPITAL RESOURCES STATUS

3.2.7 SUPPORITNG ELEMENTS

A. XML SCHEMA FOR THE EDXL Hospital AVailability Exchange (HAVE)

B. EDXL-HAVE EXAMPLE

C. OASIS GML PROFILE NOTE

C.1 geo-oasis ELEMENTS

C.2 GROUPS

C.3 geo-oasis SCHEMA

D. ACKNOWLEDGEMENTS

E. REVISION HISTORY

1. Introduction

Overview

1.1.1 Purpose

HAVE is a draft XML specification 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 kids 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 EDXL HAVE comprises of the following elements:

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

1.2 Terminology

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

AHA	American Hospital Association
EDXL	Emergency Data Exchange Language
EOC	Emergency Operations Center
EOP	Emergency Operations Plan
EMS	Emergency Medical Services
GJXDM	Global Justice XML Data Model
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/tr8350_2.html, NGA Technical Report TR8350.2, January 2000.

[XML 1.0]

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

[namespaces]

T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C REC-xml-names-19990114, January 1999.

[dateTime]

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

[GML]

Open Geospatial Consortium, OpenGIS® Geography Markup Language (GML)

[ISO DIS 19111]

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

1.4 Non-Normative References

EDXL HAVE Standard Requirements Specification
EDXL HAVE Standard Requirements Specification, http://www.oasis-open.org/apps/org/workgroup/emergency/document.php?document_id=16399, January 2006.

EDXL HAVE Requirements Supplement
EDXL HAVE Requirements Supplement, http://www.oasis-open.org/apps/org/workgroup/emergency/document.php?document_id=16400, January 2006.

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/

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

Statewide Hospital Status Information System Terminology and Data Collection Elements
Virginia Hospital & Healthcare Association (VHHA), http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/18019/State%20IT%20terms%201-31-05.doc

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

EDXL Distribution Element (DE) Standard
EDXL Distribution Element (DE) Standard v1.0, http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/17962/EDXL-DE_Spec_v1.0%2814%29.pdf, March 2006

EDXL Resource Messaging (RM) DRAFT
EDXL Resource Messaging (RM) Draft Requirements Specification, http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/14310/EDXL_ResourceDraft_OASIS082005.doc

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

[GML v3.1.1]
Open Geospatial Consortium, OpenGIS® Geography Markup Language (GML) Encoding Specification (GML) Version 3.1.1, http://portal.opengeospatial.org/files/index.php?artifact_id=4700, 2004

GML Profile for OASIS EM
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

The Hospital AVailability Specification SHOULD:

The EDXL HAVE standard MUST:

Allow medical and healthcare organizations to communicate their status and availability information.
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).
Be able to be used as a payload or content element with the EDXL Distribution Element.
Allow the communication of status information of one or more organizations in a single exchange.
Allow the communication of the organization’s status and availability information with regard to its facilities, operations, services, and resources.
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 (normative)

3.1 DOCUMENT OBJECT MODEL

EDXL-HAVE DOM

Figure 1: EDXL-HAVE DOM

3.2 DATA DICTIONARY

Element	<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.
Comments	The EDXL-HAVE has no independent routing mechanism, so it requires a routing mechanism that is consistent with the EDXL-DE distribution types. It must contain one or more <Hospital> elements.
Sub-elements	Hospital
Used In	Top level element

Element	<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.
Comments	Multiple Instances of the <Hospital> element MAY occur within the <HospitalStatus> container element.
Sub-elements	OrganizationInformation EmergencyDepartmentStatus HospitalBedCapacityStatus ServiceCoverageStatus HospitalFacilityStatus HospitalResourcesStatus LastUpdateTime
Used In	Top level element

3.2.1 Organization Information

Element	<OrganizationInformation>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once, top level container
Definition	The container element for organization information elements.
Comments	The generic element Organization refers to the entity that is providing the data. This generic name is used throughout this document. Typically, this will include hospitals, nursing care centers, trauma centers etc.
Sub-elements	OrganizationID OrganizationIDProviderName OrganizationName OrganizationTypeText OrganizationLocation CommentText
Used In	Top level element

Element	<OrganizationID>
Type	xsd:string
Usage	CONDITIONAL
Definition	An identifier of an organization based on the type of organization it is, e.g., for a school, this would be a school identifier, for a lien holder, this would be a lien holder identifier, for a court, this would be a court identifier. Definition Source: GJXDM.
Comments	Either the <OrganizationName> or the <OrganizationID> MUST be present. For the purposes of this document, <OrganizationID> is used to specify the identifier for the healthcare organization. This is a unique identifier for the hospital.
Used In	OrganizationInformation

Element	<OrganizationIDProviderName>
Type	xsd:string
Usage	CONDITIONAL
Definition	The name of the provider that has provided the identification scheme. This could also be the name a particular identification list.
Comments	There are different identification schemes that provide unique identifiers to healthcare organizations. This element can be used to provide a reference to the classification/identification scheme that is being used. If <OrganizationID> is used, <OrganizationIDProviderName> must be used. Example: American Hospital Association
Used In	OrganizationInformation

Element	<OrganizationName>
Type	xsd:string
Usage	CONDITIONAL
Definition	The name of the organization. Definition Source: GJXDM
Comments	Either the <OrganizationName> or the <OrganizationID> MUST be present. If multiple branches of a hospital are present, the <OrganizationName> may include the location information as well. Example: ABC hospital at Fairfax and ABC hospital at Alexandria
Used In	OrganizationInformation

Element	<OrganizationTypeText>
Type	xsd:string
Usage	OPTIONAL
Definition	The general functional type of the organization. Definition Source: GJXDM
Comments	Example: Hospital, Nursing Center etc.
Used In	OrganizationInformation

Element	<OrganizationLocation>
Type	XML Structure
Usage	OPTIONAL
Definition	The container element for the specifying the location of the organization.
Comments	The location consists of the address and the geographic location (which is specified as a point). The geographic coordinates specified in <point> must match the address.
Sub-elements	StreetFullText LocationCityName LocationCountyName LocationStateName LocationPostalCodeID LocationCountryName OrganizationGeoLocation
Used In	Top level element

Element	<StreetFullText>
Type	xsd:string
Usage	OPTIONAL
Definition	A complete street reference, e.g., "123 Main Street NW". Definition Source: GJXDM
Used In	OrganizationInformation/OrganizationLocation

Element	<LocationCityName>
Type	xsd:string
Usage	OPTIONAL
Definition	A name of a city or town. Definition Source: GJXDM
Comments
Used In	OrganizationInformation/OrganizationLocation

Element	<LocationCountyName>
Type	xsd:string
Usage	OPTIONAL
Definition	A name of a county or parish Definition Source: GJXDM
Comments
Used In	OrganizationInformation/OrganizationLocation

Element	<LocationStateName>
Type	xsd:string
Usage	OPTIONAL
Definition	A name of a state, commonwealth, province, or other sub-region of a country Definition Source: GJXDM
Comments
Used In	OrganizationInformation/OrganizationLocation

Element	<LocationPostalCodeID>
Type	xsd:string
Usage	OPTIONAL
Definition	A zip code or postal code Definition Source: GJXDM
Used In	OrganizationInformation/OrganizationLocation

Element	<LocationCountryName>
Type	xsd:string
Usage	OPTIONAL
Definition	A name of a country Definition Source: GJXDM
Used In	OrganizationInformation/OrganizationLocation

Element	<OrganizationGeoLocation>
Type	XML Structure
Usage	OPTIONAL
Definition	The container element for specifying the geo-coded address.
Comments	This specification uses the OASIS GML profile for specifying the geo-location and its attributes and MUST match the civil address. It contains the <geo-oasis:where> element Note: See Appendix C
Sub-elements	point
Used In	OrganizationInformation/OrganizationLocation

Element	<where>
Type	XML Structure
Usage	OPTIONAL
Definition	Root property element of a geo-oasis GML instance
Comments	The <where> element has the following sub-elements: <point>, <line>, <polygon> and <envelope> For the purpose of this specification, it is constrained to use only the <point> element. See Appendix C.
Sub-elements/Attributes	point whereAttrGroup
Used In	OrganizationInformation/OrganizationLocation/OrganizationGeoLocation

Element	<point>
Type	geo-oasis: SimplePositionType
Usage	OPTIONAL
Definition	Point property element containing a pair of coordinates representing latitude then longitude in the World Geodetic System 1984 [WGS84] coordinate reference system.
Comments	The geo-coded address of the civil location. <OrganizationGeoLocation> <geo-oasis: where> <geo-oasis: point>45.256 -71.92></geo-oasis: point> </geo-oasis: where> </OrganizationGeoLocation> See Appendix C for note on OASIS GML profile.
Used In	OrganizationInformation/OrganizationLocation/OrganizationGeoLocation

3.2.2 Emergency Department Status

Element	<EmergencyDepartmentStatus>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once, top level container
Definition	The container of all of the elements related to the emergency department status.
Comments	It describes the ability of this emergency department to treat patients.
Sub-elements	EMSTraffic EMSCapacity EMSCensus EMSAmbulanceStatus EMSAirTransportStatus CommentText
Used In	Top level element

Element	<EMSTraffic>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once, top level container
Definition	The container of all of the elements related to the status of operations of EMS traffic. It defines the ability of this emergency department to receive patients via emergency medical services.
Comments
Sub-elements	EMSTrafficStatus EMSTrafficReason CommentText
Used In	EmergencyDepartmentStatus

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

Element	<EMSTrafficReason>
Type	xsd:string with restrictions
Usage	OPTIONAL
Definition	It is used to report the contributing factor to an EMSTraffic Status.
Comments
Used In	EmergencyDepartmentStatus/EMSTraffic

Element	<EMSCapacity>
Type	XML Structure
Usage	OPTIONAL
Definition	The number of each triage patient type the hospital can accept.
Comments
Sub-elements	TriageCount
Used In	EmergencyDepartmentStatus

Element	<EMSCensus>
Type	XML Structure
Usage	OPTIONAL
Definition	The number of each triage patient type the overall hospital currently has.
Comments
Sub-elements	TriageCount
Used In	EmergencyDepartmentStatus

Element	<TriageCount>
Type	XML Structure
Usage	OPTIONAL
Definition	The number of each triage patient type the overall hospital currently has.
Comments
Sub-elements	TriageRed TriageYellow TriageGreen TriageBlack
Used In	EmergencyDepartmentStatus/EMSCensus EmergencyDepartmentStatus/EMSCapacity

Element	<TriageRed>
Type	xsd:integer
Usage	OPTIONAL
Definition	Number of victims with immediate needs.
Comments
Used In	EmergencyDepartmentStatus/EMSCapacity/TriageCount EmergencyDepartmentStatus/EMSCensus/TriageCount

Element	<TriageYellow>
Type	xsd:integer
Usage	OPTIONAL
Definition	Number of victims with delayed needs
Comments
Used In	EmergencyDepartmentStatus/EMSCapacity/TriageCount EmergencyDepartmentStatus/EMSCensus/TriageCount

Element	<TriageGreen>
Type	xsd:integer
Usage	OPTIONAL
Definition	Number of victims with minor needs
Comments
Used In	EmergencyDepartmentStatus/EMSCapacity/TriageCount EmergencyDepartmentStatus/EMSCensus/TriageCount

Element	<TriageBlack>
Type	xsd:integer
Usage	OPTIONAL
Definition	Number of deceased victims
Used In	EmergencyDepartmentStatus/EMSCapacity/TriageCount EmergencyDepartmentStatus/EMSCensus/TriageCount

Element	<EMSAmbulanceStatus>
Type	XML Structure
Usage	OPTIONAL
Definition	The container element to indicate the status and offload time for ambulance capabilities.
Comments	The time it takes to transfer care of a patient to hospital staff, thereby freeing the ambulance for assignment. Select from Normal or Delayed and/or specify the average offload average offload time in minutes.
Sub-elements	Offload CommentText
Used In	EmergencyDepartmentStatus

Element	<EMSAirTransportStatus>
Type	XML Structure
Usage	OPTIONAL
Definition	The container element to indicate the status and offload time for ambulance capabilities.
Comments	The time it takes to transfer care of a patient to hospital staff, thereby freeing the ambulance for assignment. Select from Normal or Delayed and/or specify the average offload average offload time in minutes.
Sub-elements	Offload CommentText
Used In	EmergencyDepartmentStatus

Element	<Offload>
Type	XML Structure
Usage	OPTIONAL
Definition	Indicator of offload times of ambulance capabilities. The time it takes to transfer care of a patient to hospital staff, thereby freeing the transport for assignment.
Sub-elements	EMSOffloadStatus EMSOffloadMinutes
Used In	EmergencyDepartmentStatus/EMSAmbulanceStatus EmergencyDepartmentStatus/EMSAirTransportStatus

Element	<EMSOffloadStatus>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	Indicator of offload times of ambulance capabilities.
Comments	Values: Normal – The time required to offload the patient is typical Delayed – The time required to offload the patient is longer than typical.
Used In	EmergencyDepartmentStatus/EMSAmbulanceStatus/Offload EmergencyDepartmentStatus/EMSAirTransportStatus/Offload

Element	<EMSOffloadMinutes>
Type	xsd: integer
Usage	OPTIONAL
Definition	Average offload time in minutes.
Comments
Used In	EmergencyDepartmentStatus/EMSAmbulanceStatus/Offload EmergencyDepartmentStatus/EMSAirTransportStatus/Offload

3.2.3 HospitalBedCapacityStatus

Element	<HospitalBedCapacityStatus>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once, top level container
Definition	The container of all of the elements related to the hospital bed capacity and status.
Comments	For each of the bed types (AdultICU, MedicalSurgical, etc.), if needed, a collection of named sub-types can be provided. The totals of sub-categories SHOULD equal the capacity data specified in the parent. Example, a hospital may sub-categorize Adult ICU beds into Surgery, Cardiac, General and Neuro.
Sub-elements	BedCapacity
Used In	Top level element

Element	<BedCapacity>
Type	XML Structure
Usage	REQUIRED; May use multiple
Definition	Container element to identify the number of available beds.
Comments	Each Bed Type and the sub-categories under it must be encapsulated by a <BedCapacity> element. Multiple instances of <BedCapacity> elements are allowed.
Sub-elements	BedType SubCategoryBedType CommentText Capacity
Used In	HospitalBedCapacityStatus

Element	<BedType>
Type	xsd: string with restrictions
Usage	OPTIONAL, May use multiple
Definition	Enumerated list of available Bed Types.
Comments	Values: AdultICU - Capacity status for adult ICU bed type. These can support critically ill or injured patients, including ventilator support. This category includes all major subtypes of ICU beds, including neuro, cardiac, trauma, or medical, with the exception that this category does not include burn ICU beds. MedicalSurgical - Capacity status for medical-surgical beds. These are also thought of as ward beds. These beds may or may not include cardiac telemetry capability Burn - Capacity status for burn beds. These are thought of as burn ICU beds, either approved by the American Burn Association or self-designated. These beds are NOT to be included in other ICU bed counts. PediatricICU Capacity status for pediatric ICU beds. This is similar to adult ICU beds, but for patients 17-years-old and younger. Pediatrics Capacity status for pediatrics beds. These are ward medical/surgical beds for patients 17-years-old and younger. Psychiatric Capacity status for psychiatric beds. These are ward beds on a closed/locked psychiatric unit or ward beds where a patient will be attended by a sitter. NegativeFlowIsolation Capacity status for negative airflow isolation beds. These provide respiratory isolation. NOTE: This value may represent available beds included in the counts of other types. OtherIsolation Capacity status for other isolation beds. These provide isolation where airflow is not a concern. NOTE: This value may represent available beds included in the counts of other types. OpeatingRooms Capacity status for operating rooms which are equipped staffed and could be made available for patient care in a short period of time. Each bed type (AdultICU, MedicalSurgical, etc.) may optionally contain a collection of named sub-categories. The totals of sub-categories should equal the capacity data specified in the parent. Example, a hospital may sub-categorize Adult ICU beds into Surgery, Cardiac, General and Neuro.
Used In	HospitalBedCapacityStatus/BedCapacity

Element	<SubCategoryBedType>
Type	xsd: string
Usage	OPTIONAL, May use multiple
Definition	The name of the sub-category bed type
Comments	Each bed type may have many one or more named sub-type categories. The totals of each should add up to amounts specified in the parent bed capacity.
Used In	HospitalBedCapacityStatus/BedCapacity

Element	<Capacity>
Type	xsd: string
Usage	OPTIONAL, May use multiple
Definition	Container element to define the capacity information of each specified bed type or sub category bed type.
Comments
Sub-elements	CapacityStatus AvailableCount BaselineCount AdditionalCapacityCount24Hr AdditionalCapacityCount72Hr
Used In	HospitalBedCapacityStatus/BedCapacity

Element	<CapacityStatus>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	Indicator of status of bed type or sub-category bed type.
Comments	Values: VacantAvailable – The type of bed is available. NotAvailable – The type of bed is not available.
Used In	HospitalBedCapacityStatus/BedCapacity/Capacity HospitalBedCapacityStatus/BedCapacity/SubCategoryBedCapacity/Capacity

Element	<AvailableCount>
Type	xsd: integer
Usage	OPTIONAL
Definition	The number of vacant/available beds to which patients can be immediately transported.
Comments	These must include supporting space, equipment, medical material, ancillary and support services, and staff to operate under normal circumstances. These beds are licensed, physically available and have staff on hand to attend to the patient who occupies the bed.
Used In	HospitalBedCapacityStatus/BedCapacity/Capacity HospitalBedCapacityStatus/BedCapacity/SubCategoryBedCapacity/Capacity

Element	<BaselineCount>
Type	xsd: integer
Usage	OPTIONAL
Definition	The maximum (baseline) number of beds in this category
Comments
Used In	HospitalBedCapacityStatus/BedCapacity/Capacity HospitalBedCapacityStatus/BedCapacity/SubCategoryBedCapacity/Capacity

Element	<AdditionalCapacityCount24Hr>
Type	xsd: integer
Usage	OPTIONAL
Definition	Estimate of the beds, above the current number, that could be made vacant/available within 24 hours.
Comments	This includes institutional surge beds as well as beds made available by discharging or transferring patients.
Used In	HospitalBedCapacityStatus/BedCapacity/Capacity HospitalBedCapacityStatus/BedCapacity/SubCategoryBedCapacity/Capacity

Element	<AdditionalCapacityCount72Hr>
Type	xsd: integer
Usage	OPTIONAL
Definition	Estimate of the beds, above the current number, that could be made vacant/available within 72 hours.
Comments	This includes institutional surge beds as well as beds made available by discharging or transferring patients.
Used In	HospitalBedCapacityStatus/BedCapacity/Capacity HospitalBedCapacityStatus/BedCapacity/SubCategoryBedCapacity/Capacity

3.2.4 Service Coverage Status

Element	<ServiceCoverageStatus>
Type	XML Structure
Usage	OPTIONAL
Definition	The container element of all the elements of service coverage. This includes both the necessary staff and facilities. Indicator of the availability of specialty service coverage.
Comments	Some of the services capabilities are broken down into subtypes. This is to allow organizations to designate subtypes, if available. If not, only the higher level specialties are reported.
Sub-elements	Burn Cardiology InfectiousDiseases Orthopedic Neonatology Neurology OBGYN Psychiatric Surgery CommentText
Used In	Top level element

Element	<Burn>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of burn center services.
Comments	Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus

Element	<Cardiology>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of cardiology services.
Comments	Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus

Element	<InfectiousDiseases>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of infectious diseases services.
Comments	Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus

Element	<Neonatology>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of neonatology services.
Comments	Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus

Element	<Neurology>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of neurology services. Values: True - This type of services is available. False - This type of services is not available.
Comments
Used In	ServiceCoverageStatus

Element	<Orthopedic>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of orthopedic services.
Comments	Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus

Element	<OBGYN>
Type	xsd: boolean
Usage	OPTIONAL; SUPERTYPE
Definition	The availability of OBGYN services.
Comments	Values: True - This type of services is available. False - This type of services is not available. This services capability is broken down into the below subtypes. This is to allow organizations to designate subtypes, if available. Others can report just the higher level specialties.
Sub-elements	OBGYN LaborDelivery
Used In	ServiceCoverageStatus

Element	<OBGYN>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The Sub-type element of the OBGYN services.
Comments	Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/OBGYN

Element	<LaborDelivery>
Type	xsd: boolean
Usage	OPTIONAL
Definition	Sub-type element of the OBGYN Services. Availability of Labor Delivery services.
Comments	Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/OBGYN

Element	<Psychiatric>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of psychiatric services.
Comments	This services capability is broken down into the below subtypes. This is to allow organizations to designate subtypes, if available. Values: True - This type of services is available. False - This type of services is not available. Others can report just the higher level specialties.
Sub-elements	AdultGeneral Pediatric
Used In	ServiceCoverageStatus

Element	<AdultGeneral>
Type	xsd: boolean
Usage	OPTIONAL
Definition	Availability of Adult General Psychiatric services.
Comments	Sub-type element of the psychiatric services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Psychiatric

Element	<Pediatric>
Type	xsd: boolean
Usage	OPTIONAL
Definition	Availability of Pediatric Psychiatric services.
Comments	Sub-type element of the psychiatric services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Psychiatric

Element	<Surgery>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of general surgery services.
Comments	Values: Available - This type of services is available. NotAvailable - This type of services is not available. This services capability is broken down into the below subtypes. This is to allow organizations to designate subtypes, if available. Others can report just the higher level specialty.
Sub-elements	General AdultGeneralSurgery Pediatrics Orthopedics NeuroSurgery Facial CardioThoracic Hand Reimplantation Spinal Vascular Anesthesia
Used In	ServiceCoverageStatus

Element	<General>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of general surgical services.
Comments	Sub-type element of the adult general services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<AdultGeneralSurgery>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of adult general services.
Comments	Sub-type element of the adult general services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Pediatrics>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of Pediatrics general surgical services.
Comments	Sub-type element of pediatrics general surgical services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Orthopedics>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of Orthopedic surgical services.
Comments	Sub-type element of orthopedic surgical services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<NeuroSurgery>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of Neurosurgery services.
Comments	Sub-type element of neurosurgery services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Facial>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of facial surgical services.
Comments	Sub-type element of facial surgery services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<CardioThoracic>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of cardiothoracic surgical services.
Comments	Sub-type element of cardiothoracic services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Hand>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of hand surgery services.
Comments	Sub-type element of cardiothoracic services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Reimplantation>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of reimplantation surgical services.
Comments	Sub-type element of reimplantation surgical services. Values: Available - This type of services is available. NotAvailable - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Spinal>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of spinal surgical services.
Comments	Sub-type element of spinal surgical services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Vascular>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of vascular surgical services.
Comments	Sub-type element of vascular surgery services. Values: True - This type of services is available. False - This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

Element	<Anesthesia>
Type	xsd: boolean
Usage	OPTIONAL
Definition	The availability of anesthesia services.
Comments	Sub-type element of anesthesia services. Values: True – This type of services is available. False – This type of services is not available.
Used In	ServiceCoverageStatus/Surgery

3.2.5 Hospital Facility Status

Element	<HospitalFacilityStatus>
Type	XML Structure
Usage	REQUIRED, MUST be used once and only once, top level container
Definition	The container of all of the elements related to the status of the facility.
Comments
Sub-elements	EOCStatus EOCPlan ClinicalStatus DeconCapacity MorgueCapacity FacilityStatus SecurityStatus Activity24Hr CommentText
Used In	Top level element

Element	<EOCStatus>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	Whether the Emergency Operations Center (EOC) is currently operating.
Comments	Values: Active. Inactive Note: Note the EOC is typically activated in disasters or other special situations, and this term is NOT intended to indicate whether the clinical emergency department is open for patient care.
Used In	HospitalFacilityStatus

Element	<EOCPlan>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	Whether the hospital has activated its Emergency Operations Plan (EOP)
Comments	Values: Active Inactive
Used In	HospitalFacilityStatus

Element	<ClinicalStatus>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	The clinical status of the facility.
Comments	Values: Normal - Hospital clinical resources are operating within normal conditions. Level1 - Hospital clinical resources are operating at Level-1 surge conditions. Level2 - Hospital clinical resources are operating at Level-2 surge conditions. Full - Hospital clinical resources are exceeded and acceptable care cannot be provided to additional patients. Diversion or community surge response is required.
Used In	HospitalFacilityStatus

Element	<DeconCapacity>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	The capacity for chemical/biological/radiological patient decontamination.
Comments	Values: Inactive - Not being used, but available if needed Open - In use and able to accept additional patients Full - In use at maximum capacity Exceeded - Needs exceed available capacity
Used In	HospitalFacilityStatus

Element	<MorgueCapacity>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	The status of the morgue capacity.
Comments	Values: Open - Space is available Full - All normal space is in use Exceeded - Storage needs exceed available space
Used In	HospitalFacilityStatus

Element	<FacilityStatus>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	The status of the facility.
Comments	Values: Normal - No conditions exist that adversely affect the general operations of the facility. Compromised - General operations of the facility have been affected due to damage, operating on emergency backup systems, or facility contamination. Evacuating - Indicates that a hospital is in the process of a partial or full evacuation. Closed - Indicates that a hospital is no longer capable of providing services and only emergency services/restoration personnel may remain in the facility.
Used In	HospitalFacilityStatus

Element	<SecurityStatus>
Type	xsd: string with restrictions
Usage	OPTIONAL
Definition	The status of security procedures in the hospital.
Comments	Values: Normal - The hospital is operating under routine security procedures. Elevated - The hospital has activated increased security procedures (awareness, surveillance) due to a potential threat, or specific security related event i.e. increase in local threat level, VIP, bomb threat. RestrictedAccess - Based on security needs, the hospital has activated procedures to allow access to the facility through a reduced number of controlled entrances. Lockdown - Based on security needs, the hospital has activated procedures to control entry to the facility to authorized persons only. Quarantine - Based on a public health emergency, the entry and exit of the facility is controlled by public health officials.
Used In	HospitalFacilityStatus

Element	<Activity24Hr>
Type	XML Structure
Usage	OPTIONAL
Definition	The container element for reporting activities in the last 24 hours.
Comments	The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.
Sub-elements	Admissions Discharges Deaths
Used In	HospitalFacilityStatus

Element	<Admissions>
Type	xsd: integer
Usage	OPTIONAL
Definition	The number of admissions in the last 24 hours.
Comments	The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.
Used In	HospitalFacilityStatus/Activity24Hr

Element	<Discharges>
Type	xsd: integer
Usage	OPTIONAL
Definition	The number of discharges in the last 24 hours.
Comments	The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.
Used In	HospitalFacilityStatus/Activity24Hr

Element	<Deaths>
Type	xsd: integer
Usage	OPTIONAL
Definition	The number of deaths in the last 24 hours.
Comments	The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.
Used In	HospitalFacilityStatus/Activity24Hr

3.2.6 Hospital Resources Status