Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 1.0

Public Review Draft 05

04 March 2008

Specification URIs:

This Version:

http://docs.oasis-open.org/emergency/edxl-have/pr05/emergency_edxl_have-1.0-spec-pr05.doc (Authoritative)

http://docs.oasis-open.org/emergency/edxl-have/pr05/emergency_edxl_have-1.0-spec-pr05.html

http://docs.oasis-open.org/emergency/edxl-have/pr05/emergency_edxl_have-1.0-spec-pr05.pdf

Previous Version:

http://docs.oasis-open.org/emergency/edxl-have/pr03/emergency_edxl_have-1.0-spec-pr03.doc

http://docs.oasis-open.org/emergency/edxl-have/pr03/emergency_edxl_have-1.0-spec-pr03.html

http://docs.oasis-open.org/emergency/edxl-have/pr03/emergency_edxl_have-1.0-spec-pr03.pdf

Latest Version:

http://docs.oasis-open.org/emergency/edxl-have/v1.0/emergency_edxl_have-1.0.doc

http://docs.oasis-open.org/emergency/edxl-have/v1.0/emergency_edxl_have-1.0.html

http://docs.oasis-open.org/emergency/edxl-have/v1.0/emergency_edxl_have-1.0.pdf

 

Technical Committee:

OASIS Emergency Management TC

Chair(s):

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

Editor(s):

Sukumar Dwarkanath, Associate Member - <Sukumar_Dwarkanath@sra.com>

Related work:

This specification is related to:

·         EDXL-DE v1.0

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

Copyright © OASIS Open 2008. All Rights Reserved.

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

1.1 OVERVIEW.. 5

1.1.1 PURPOSE. 5

1.1.2 HISTORY. 5

1.1.3 STRUCTURE. 5

1.2 TERMINOLOGY. 6

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

 

<HospitalStatus>

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

<Hospital>

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

<Organization>

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

<EmergencyDepartmentStatus>

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

<HospitalBedCapacityStatus>

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.

<ServiceCoverageStatus>

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.

<HospitalFacilityStatus>

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

<HospitalResourcesStatus>

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

<LastUpdateTime>

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

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

 

 

Element

<have:TriageCodeListURN>

Type

xsd:anyURI

Usage

CONDITIONAL

Definition

The name of a certified list maintained by the Community of Interest (COI) for the value referenced. The list identifies the triage codes used by the particular community.

Constraints

1.       <Hospital> element MAY contain a <TriageCodeListURN> element as specified in the schema, but MUST NOT contain more than one such element.

2.       If a <TriageCodeListURN> element is present within a <Hospital> element, it MUST precede the first <TriageCode> element within that <Hospital> element.

3.       If a <TriageCodeListURN> element is present within a <Hospital> element and is not empty, then the values of all the <TriageCodeValue> elements within that <Hospital> element MUST be interpreted according to the URN in the <TriageCodeListURN> element.

4.       If a <TriageCodeListURN> element is not present within a <Hospital> element or it is present but empty, then the values of all the <TriageCodeValue> elements within that <Hospital> element MUST be interpreted according to the following URN:

urn:oasis:names:tc:emergency:have:1.1:triagecolorcode

which identifies the code list specified in the data dictionary entry for the element <TriageCodeValue>.

Used In

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCensus/TriageCount

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCapacity/TriageCount

 

Element

<have:TriageCode>

Type

Value and Associated Lists

Usage

OPTIONAL, May use Multiple

Definition

The container element to specify the triage values and their quantity.

Constraints

1.       Multiple instances of the <TriageCodeValue> MAY occur with a single <TriageCodeListURN>

2.       Each <TriageCodeValue> and its associated <TriageCountQuantity> MUST be enclosed in <TriageCode>

Comments

1.       The list and associated value(s) is in the form:

<have:TriageCodeListURN>urn:oasis:names:tc:emergency:have:1.0:triagecolorcode</have:TriageCodeListURN>

<have:TriageCode>

<have:TriageCodeValue>Red</have:TriageCodeValue>

<have:TriageCountQuantity>20</have:TriageCountQuantity>

</have:TriageCode>


where the content of <TriageCodeListUrn> is the Uniform Resource Name of a published list of values and definitions, and the content of <TriageCodeListValue> is a string (which may represent a number) denoting the value itself.

Sub –elements

·         TriageCodeValue

·         TriageCountQuantity

Used In

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCensus/TriageCount

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCapacity/TriageCount

 

Element

<have:TriageCodeValue>

Type

xsd:string

Usage

CONDITIONAL, MAY use multiple

Definition

A value from a certified list maintained by the Community of Interest (COI) for the referenced element.

Constraints

1.       The list of values SHOULD be from the list identified in <TriageCodeListURN>

2.       If a <TriageCodeValue> is specified, a <TriageCountQuantity> element MUST be specified.

Default Code List Values:

·         Red – Number of victims with immediate needs.

·         Yellow - Number of victims with delayed needs

·         Green - Number of victims with minor needs

·         Black - Number of deceased victims

Used In

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCensus/TriageCount

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCapacity/TriageCount

 

Element

<have:TriageCountQuantity>

Type

xsd:integer

Usage

CONDITIONAL, MAY use multiple

Definition

The integer value associated with the Triage Code value. 

Constraints

1.       If a <TriageCodeValue> is specified, a <TriageCountQuantity> element MUST be specified.

Used In

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCensus/TriageCode

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCapacity/TriageCode

 

Example:

<have:EMSCapacity>

   <have:TriageCodeListURN>

urn:oasis:names:tc:emergency:have:1.0:triagecolorcode

</have:TriageCodeListURN>

<have:TriageCode>

<have:TriageCodeValue>Red</have:TriageCodeValue>

<have:TriageCountQuantity>20</have:TriageCountQuantity>

</have:TriageCode>

<have:TriageCode>

<have:TriageCodeValue>Yellow</have:TriageCodeValue>

<have:TriageCountQuantity>30</have:TriageCountQuantity>

</have:TriageCode>

<have:TriageCode>

<have:TriageCodeValue>Green</have:TriageCodeValue>

<have:TriageCountQuantity>40</have:TriageCountQuantity>

</have:TriageCode>

<have:TriageCode>

<have:TriageCodeValue>Black</have:TriageCodeValue>

<have:TriageCountQuantity>10</have:TriageCountQuantity>

</have:TriageCode>

</have:EMSCapacity>

 

Element

<have:EMSAmbulanceStatus>

Type

Offload

Usage

OPTIONAL

Definition

The container element to indicate the status and offload time for ground ambulance capabilities.

Comments

1.       The time it takes to transfer care of a patient to hospital staff, thereby freeing the ambulance for assignment.

2.       Select from Normal or Delayed and/or specify the average offload average offload time in minutes.

Sub-elements

·         CommentText

Used In

HospitalStatus/Hospital/EmergencyDepartmentStatus

 

Element

<have:EMSAirTransportStatus>

Type

Offload

Usage

OPTIONAL

Definition

The container element to indicate the status and offload time for air ambulance capabilities.

Comments

1.       The time it takes to transfer care of a patient to hospital staff, thereby freeing the ambulance for assignment.

2.       Select from Normal or Delayed and/or specify the average offload average offload time in minutes.


 

Element

<have:EMSOffloadStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

Indicator of offload times of ambulance capabilities. 

Constraints

Values:

1.       Normal – The time required to offload the patient is typical

2.       Delayed – The time required to offload the patient is longer than typical.

Used In

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSAmbulanceStatus/Offload

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSAirTransportStatus/Offload

 

Element

<have:EMSOffloadMinutes>

Type

xsd:integer

Usage

OPTIONAL

Definition

The average time to offload a patient, in minutes.

Used In

EmergencyDepartmentStatus/EMSAmbulanceStatus/Offload

EmergencyDepartmentStatus/EMSAirTransportStatus/Offload


3.2.4 HOSPITAL BED CAPACITY STATUS

 

Note: Please refer to Appendix B for definitions for bed types.

 

Element

<have:HospitalBedCapacityStatus>

Type

XML Structure

Usage

OPTIONAL

Definition

The container of all of the elements related to the hospital bed capacity and status. 

Constraints

1.       For each of the bed types (AdultICU, MedicalSurgical, etc.), if needed, a collection of named sub-types MAY be provided. 

2.       A hospital MAY specify the number of sub-categories without specifying all of the sub-categories.

3.       The totals of sub-categories MAY equal the capacity data specified in the parent. 

Comments

Example, a hospital may sub-categorize Adult ICU beds into Surgery, Cardiac, General and Neuro. 

Sub-elements

·         BedCapacity

Used In

HospitalStatus/Hospital

 

Element

<have:BedCapacity>

Type

XML Structure

Usage

CONDITIONAL; May use multiple

Definition

Container element to identify the number of available beds.

Constraints

1.       Multiple instances of <BedCapacity> elements MAY be specified.

2.       Each parent <BedType> element and its associated sub-category bed types MUST be encapsulated with a <BedCapacity> element.

Sub-elements

·         BedType

·         SubCategoryBedType

·         CommentText

·         Capacity

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus

 

Element

<have:BedType>

Type

xsd:string with restrictions

Usage

OPTIONAL, May use multiple

Definition

Enumerated list of available Bed Types.

Constraints

1.       Each bed type (AdultICU, MedicalSurgical, etc.) MAY optionally contain a collection of named sub-categories.

2.       The totals of sub-categories MAY equal the capacity data specified in the parent.

Comments

Values:

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

2.       PediatricICU

·         Capacity status for pediatric ICU beds. This is similar to adult ICU beds, but for patients 17-years-old and younger.

3.       NeonatalICU

·         Capacity status for nenonatal ICU beds.

4.       EmergencyDepartment

·         Capacity status for beds within the Emergency Department used for acute care.

5.       NurseryBeds

·         Capacity Status for Neonatal or newborn care beds including all bed types other than Neonatal ICU

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

7.       RehabLongTermCare – Capacity Status for Rehabilitation/Long term care beds.

·         Beds designated as long term care rehabilitation. These do not include floor beds.

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

9.       Pediatrics

·         Capacity status for pediatrics beds. These are ward medical/surgical beds for patients 17-years-old and younger.

10.   AdultPsychiatric

·         Capacity status for adult psychiatric beds. These are ward beds on a closed/locked psychiatric unit or ward beds where a patient will be attended by a sitter.

11.   PediatricPsychiatric

·         Capacity status for pediatric psychiatric beds. These are ward beds on a closed/locked psychiatric unit or ward beds where a patient will be attended by a sitter

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

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

14.   OperatingRooms

·         Capacity status for operating rooms which are equipped staffed and could be made available for patient care in a short period of time.

Example, a hospital may sub-categorize Adult ICU beds into Surgery, Cardiac, General and Neuro.

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity

 

Element

<have:SubCategoryBedType>

Type

xsd:string

Usage

OPTIONAL, MAY use multiple

Definition

The name of the sub-category bed type

Constraints

1.       Each bed type MAY have many one or more named sub-type categories.

2.       If one or more sub category bed types are used, they MUST be preceded by the parent <BedType> element. In this case, <CapacityStatus> of the parent Bed Type MUST not be ‘NotAvailable’.

3.       Each parent <BedType> element and its associated sub-category bed types MUST be encapsulated with a <BedCapacity> element.

4.       If the capacity counts of sub-category beds are specified, they MAY not equal the capacity count of the parent bed type.

5.       In general, if capacities are specified using sub-category bed types, then only the <CapacityStatus> of the parent bed type MUST be used, and this should reflect an ‘Available’ value. No assumptions should be made about capacities that are not specified.

Comments

1.       If a <Capacity> element is specified, it pertains to the preceding <BedType> or <SubCategoryBedType> element.

Note: Please see example at the end of this section.

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity

 

Element

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

Constraints

1.       <BedType> element or <SubCategoryBedType> elements MAY have a <Capacity> element.

2.       In general, if capacities are specified using sub-category bed types, then only the <CapacityStatus> of the parent bed type MUST be used, and this MUST reflect an ‘Available’ value.

Comments

1.       If a <Capacity> element is specified, it pertains to the preceding <BedType> or <SubCategoryBedType> element.

2.       No assumptions must be made about bed capacities that are not specified.

Sub-elements

·         CapacityStatus

·         AvailableCount

·         BaselineCount

·         AdditionalCapacityCount24Hr

·         AdditionalCapacityCount72Hr

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity

 

Element

<have:CapacityStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

Indicator of status of bed type or sub-category bed type. 

Constraints

1.       Values:

·         VacantAvailable – The type of bed is available.

·         NotAvailable – The type of bed is not available.

Comments

1.       No assumptions must be made about bed capacities that are not specified.

2.       Vacant/Available Beds refers to beds that are vacant and to which patients can be immediately transported. These will 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.

Note: Please refer to appendix B

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity/Capacity

 

Element

<have:AvailableCount>

Type

xsd:integer

Usage

OPTIONAL

Definition

The number of vacant/available beds to which patients can be immediately transported. 

Comments

1.       These will include supporting space, equipment, medical material, ancillary and support services, and staff to operate under normal circumstances.

2.       These beds are licensed, physically available and have staff on hand to attend to the patient who occupies the bed.

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity/Capacity

 

Element

<have:BaselineCount>

Type

xsd:integer

Usage

OPTIONAL

Definition

The maximum (baseline) number of beds in this category.

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity/Capacity

 

Element

<have: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

1.       This includes institutional surge beds as well as beds made available by discharging or transferring patients.

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity/Capacity

 

Element

<have: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

1.       This includes institutional surge beds as well as beds made available by discharging or transferring patients.

Used In

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity/Capacity

 

 

Example 1:

 

<have:HospitalBedCapacityStatus>

 

<have:BedCapacity>

 <have:BedType> AdultICU </have:BedType>

 <have:Capacity>

  <have:CapacityStatus> Available </have:CapacityStatus>

 </have:Capacity>

 <have:SubCategoryBedType> Surgery </have:SubCategoryBedType>

 <have:Capacity>

  <have:CapacityStatus> Vacant/Available </have:CapacityStatus>

  <have:AvailableCount> 40 </have:AvailableCount>

 </have:Capacity>

 <have:SubCategoryBedType> General </have:SubCategoryBedType>

 <have:Capacity>

  <have:CapacityStatus> Vacant/Available </have:CapacityStatus>

  <have:AvailableCount> 20 </have:AvailableCount>

 </have:Capacity>

</have:BedCapacity>

 

Example 2:

 

<have:HospitalBedCapacityStatus>

 <have:BedCapacity>

  <have:BedType> AdultICU </have:BedType>

  <have:Capacity>

   <have:CapacityStatus> Available </have:CapacityStatus>

   <have:AvailableCount> 40 </have:AvailableCount>

  </have:Capacity>

 </have:BedCapacity>

</have:HospitalBedCapacityStatus>

 

 


3.2.5 SERVICE COVERAGE STATUS

 

Element

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

Constraints

1.       Either one – the parent category or the subcategories - MUST be used. Both MUST not be used together.

Comments

1.       Some of the services capabilities are broken down into subtypes. This is to allow organizations to designate subtypes, if available.

2.       If not, only the higher level specialties are reported.

3.       Organizations can either report the parent category or report the subcategories.

Sub-elements

·         Burn

·         CardiologyIndicator

·         Dialysis

·         EmergencyDepartment

·         HyperbaricChamber

·         InfectiousDiseases

·         Neonatology

·         NeurologyIndicator

·         OBGYNIndicator

·         Ophthalmology

·         Orthopedic

·         Pediatrics

·         PsychiatricIndicator

·         SurgeryIndicator

·         TransportServicesIndicator

·         TraumaCenterServicesIndicator

·         CommentText

Used In

HospitalStatus/Hospital

 

Element

<have:Burn>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of burn center services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:CardiologyIndicator>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Cardiology services.

Constraints

1.       Either one – the parent category or the subcategories - MUST be used. Both MUST not be used together.

Comments

1.       This service capability is broken down into the below subcategories. This is to allow organizations to designate subcategories, if available.

2.       Organizations can either report the parent category or report the subcategories.

Sub-elements

Choice:

·         Cardiology

·         CardiologySubType

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:Cardiology>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of cardiology services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Example:

<have:ServiceCoverageStatus>

<have:CardiologyIndicator>

<have:Cardiology>true</have:Cardiology>

</have:CardiologyIndicator>

</have:ServiceCoverageStatus>

 

Example:

<have:ServiceCoverageStatus>

 <have:CardiologyIndicator>

  <have:CardiologySubType>

   <have:CardiologyInvasive>true</have:CardiologyInvasive>

   <have:CardiologyNonInvasive>false</have:CardiologyNonInvasive>

  </have:CardiologySubType>

 </have:CardiologyIndicator>

</have:ServiceCoverageStatus>

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/CardiologyIndicator

 

Element

<have:CardiologySubType>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Cardiology services that are broken down into sub-types.

Sub-elements

Choices:

·         CardiologyInvasive

·         CardiologyNonInvasive

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/CardiologyIndicator

 

Element

<have:CardiologyInvasive>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of cardiology-invasive services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/CardiologySubType

 

Element

<have:CardiologyNonInvasive>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of cardiology-non-invasive services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/CardiologySubType

 

Element

<have:Dialysis>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of dialysis services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:EmergencyDepartment>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of Emergency Department services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:HyperbaricChamber>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of hyperbaric chamber services for decompression and/or wound care.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:InfectiousDiseases>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of infectious diseases services. 

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:Neonatology>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of neonatology services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:NeurologyIndicator>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Neurology services.

Constraints

1.       Either one – the parent category or the subcategories - MUST be used. Both MUST not be used together.

Comments

1.       This service capability is broken down into the below subcategories. This is to allow Organizations to designate subcategories, if available.

2.       Organizations can either report the parent category or report the subcategories.

Sub-elements

Choices:

·         Neurology

·         NeurologySubType

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:Neurology>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of neurology services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0”- This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/NeurologyIndicator

 

Element

<have:NeurologySubType>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Neurology services that are broken down into sub-types.

Sub-elements

Choice:

·         NeurologyInvasive

·         NeurologyNonInvasive

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/NeurologyIndicator

 

Element

<have:NeurologyInvasive>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of Neurology-Invasive services, including invasive catheterization.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0”- This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/NeurologyIndicator/NeurologySubType

 

Element

<have:NeurologyNonInvasive>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of Neurology-Non-Invasive services with no invasive catheterization capability.  

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false“ or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/NeurologyIndicator/NeurologySubType

 

Element

<have:OBGYNIndicator>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of OBGYN services.

Constraints

1.       Either one – the parent category or the subcategories - must be used. Both MUST not be used together.

Comments

1.       This service capability is broken down into the below subcategories. This is to allow Organizations to designate subcategories, if available.

2.       Organizations can either report the parent category or report the subcategories.

Sub-elements

Choices:

·         OBGYN

·         OBGYNSubType

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:OBGYN>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of OBGYN services with labor delivery services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/OBGYNIndicator

 

Element

<have:OBGYNSubType>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of OBGYN services that are broken down into sub-types.

Sub-elements

Choice:

·         OBGYNWithLaborDelivery

·         OBGYNWithoutLaborDelivery

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/OBGYNIndicator

 

Element

<have:OBGYNWithLaborDelivery>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of OBGYN services with labor delivery services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/OBGYNIndicator/OBGYNSubType

 

Element

<have:OBGYNWithoutLaborDelivery>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of OGYN Services without Labor Delivery Services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/OBGYNIndicator/OBGYNSubType

 

Element

<have:Ophthalmology>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of Ophthalmology services. 

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:Orthopedic>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of orthopedic services. 

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:Pediatrics>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of pediatric services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:PsychiatricIndicator>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Psychiatric services.

Constraints

1.       Either one – the parent category or the subcategories - MUST be used. Both MUST not be used together.

Comments

1.       This service capability is broken down into the below subcategories. This is to allow Organizations to designate subcategories, if available.

2.       Organizations MAY either report the parent category or report the subcategories.

Sub-elements

Choices:

·         Psychiatric

·         PsychiatricSubType

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:Psychiatric>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of psychiatric services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/PsychiatricIndicator

 

Element

<have:PsychiatricSubType>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Psychiatric services that are broken down into sub-types.

Sub-elements

Choice:

1.       PsychiatricAdultGeneral

2.       PsychiatricPediatric

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/PsychiatricIndicator

 

Element

<have:PsychiatricAdultGeneral>

Type

xsd:boolean

Usage

OPTIONAL

Definition

Availability of Adult General Psychiatric services.

Comments

1.       Sub-type element of the psychiatric services.

2.       Values:

·         ”true” or “1” - This type of services is available.

·         “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/PsychiatricIndicator/PsychiatricSubType

 

Element

<have:PsychiatricPediatric>

Type

xsd:boolean

Usage

OPTIONAL

Definition

Availability of Pediatric Psychiatric services.

Comments

1.       Sub-type element of the psychiatric services.

2.       Values:

·         “true” or “1” - This type of services is available.

·         “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/PsychiatricIndicator/PsychiatricSubType

 

Element

<have:SurgeryIndicator>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Surgery services.

Constraints

1.       Either one – the parent category or the subcategories - MUST be used. Both MUST not be used together.

Comments

1.       This service capability is broken down into the below subcategories. This is to allow Organizations to designate subcategories, if available.

2.       Organizations MAY either report the parent category or report the subcategories.

Sub-elements

Choices:

·         Surgery

·         SurgerySubType

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:Surgery>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of surgery services.

Comments

Values:

·         “true” or “1” - This type of services is available.

·         “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator

 

Element

<have:SurgerySubType>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The container element for specifying the availability of surgery services that are broken down into sub-types.

Sub-elements

·         General

·         AdultGeneralSurgery

·         Pediatrics

·         Orthopedics

·         NeuroSurgery

·         Facial

·         CardioThoracic

·         Hand

·         Reimplantation

·         Spinal

·         Vascular

·         Anesthesia

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator

 

Element

<have:General>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of general surgical services. 

Comments

1.       Sub-type element of the adult general services.

2.       Values:

·         “true” or “1” - This type of services is available.

·         “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:AdultGeneralSurgery>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of adult general services. 

Comments

1.       Sub-type element of the adult general services.

2.       Values:

·         “true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Pediatrics>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of Pediatrics general surgical services.

Comments

1.       Sub-type element of pediatrics general surgical services.

2.       Values:

·         ”true” or “1” - This type of services is available.

·         “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Orthopedics>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of Orthopedic surgical services.

Comments

1.       Sub-type element of orthopedic surgical services.

2.       Values:

·         ”true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:NeuroSurgery>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of Neurosurgery services.

Comments

1.       Sub-type element of neurosurgery services. 

2.       Values:

·         “true” or “1” - This type of services is available.

·         “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Facial>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of facial surgical services.

Comments

1.       Sub-type element of facial surgery services.

2.       Values:

·         ”true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:CardioThoracic>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of cardiothoracic surgical services.

Comments

1.       Sub-type element of cardiothoracic services.

2.       Values:

·         “true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Hand>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of hand surgery services.

Comments

1.       Sub-type element of hand surgery services.

2.       Values:

·         ”true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Reimplantation>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of reimplantation surgical services.  

Comments

1.       Sub-type element of reimplantation surgical services.

2.       Values:

·         Available - This type of services is available.

·         NotAvailable - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Spinal>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of spinal surgical services.  

Comments

1.       Sub-type element of spinal surgical services.

2.       Values:

·         ”true” or “1” - This type of services is available.

·         “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Vascular>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of vascular surgical services.

Comments

1.       Sub-type element of vascular surgery services.

2.       Values:

·         ”true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:Anesthesia>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of anesthesia services.

Comments

1.       Sub-type element of anesthesia services.

2.       Values:

·         “true” or “1” – This type of services is available.

·         “false” or “0” – This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/SurgeryIndicator/SurgerySubType

 

Element

<have:TransportServicesIndicator>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the availability of Transport services.

Constraints

1.       Either one – the parent category or the subcategories - MUST be used. Both MUST not be used together.

Comments

1.       This service capability is broken down into the below subcategories. This is to allow Organizations to designate subcategories, if available.

2.       Organizations MAY either report the parent category or report the subcategories.

Sub-elements

Choices:

·         TransportServices

·         TransportServicesSubType

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:TransportServices>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of transport services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/TransportServicesIndicator

 

Element

<have:TransportServicesSubType>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The container element for specifying the availability of Transport Services that are broken down into sub-types.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       ”false” or “0” - This type of services is not available.

Sub-elements

·         AirTransportServices

·         AmbulanceServices

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/TransportServicesIndicator

 

Element

<have:AirTransportServices>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of air-transport services.

Comments

1.       Sub-element of transport services.

2.       Values:

·         “true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/

ServiceCoverageStatus/TransportServicesIndicator/TransportServicesSubType

 

Element

<have:AmbulanceServices>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of transport services.

Comments

1.       Sub-element of Transport Services

2.       Values:

·         ”true” or “1” - This type of services is available.

·         ”false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/

ServiceCoverageStatus/TransportServicesIndicator/TransportServicesSubType

 

Element

<have:TraumaCenterServicesIndicator>

Type

XML Structure

Usage

CONDITIONAL; MUST be used once, if any sub-elements are used

Definition

The container element for specifying the availability of Trauma center services.

Constraints

1.       Either one – the parent category or the subcategories - MUST be used. Both MUST not be used together.

Comments

1.       This service capability is broken down into the below subcategories. This is to allow Organizations to designate subcategories, if available.

2.       Organizations MAY either report the parent category or report the subcategories.

Sub-elements

Choices:

·         TraumaCenterServices

·         TraumaCenterServicesLevel

Used In

HospitalStatus/Hospital/ServiceCoverageStatus

 

Element

<have:TraumaCenterServices>

Type

xsd:boolean

Usage

OPTIONAL

Definition

The availability of trauma center services.

Comments

Values:

1.       “true” or “1” - This type of services is available.

2.       “false” or “0” - This type of services is not available.

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/TraumaCenterServicesIndicator

 

Element

<have:TraumaCenterServicesLevel>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The service level of the trauma center.

Comments

1.       Values:

·         Level1

·         Level2

·         Level3

·         Level4

2.       For definitions please refer to the American College of Surgeons - http://www.facs.org/trauma/hospitallevels.pdf

Used In

HospitalStatus/Hospital/ServiceCoverageStatus/TraumaCenterServicesIndicator


3.2.6 HOSPITAL FACILITY STATUS

 

Element

<have:HospitalFacilityStatus>

Type

XML Structure

Usage

OPTIONAL

Definition

The container of all of the elements related to the status of the facility.  The elements in <FacilityStatus> provide a general status of the facility.

Sub-elements

·         HospitalEOCStatus

·         HospitalEOCPlan

·         ClinicalStatus

·         DeconCapacity

·         MorgueCapacity

·         FacilityStatus

·         SecurityStatus

·         Activity24Hr

·         CommentText

Used In

HospitalStatus/Hospital

 

Element

<have:HospitalEOCStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

Whether the Emergency Operations Center (EOC) is currently operating.

Comments

1.       Values:

·         Active – Indicates that the EOC has been activated. An activated EOC is fully staffed and operational.   

·         Inactive – Indicates that the EOC is not activated.

2.       Default Value: Inactive

 

Note: An EOC is a location that is activated in a disaster or emergency from which the overall command, control, communications and coordination are conducted.

 

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

HospitalStatus/Hospital/HospitalFacilityStatus

 

Element

<have:HospitalEOCPlan>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

Whether the hospital has activated its Emergency Operations Plan (EOP)

Comments

Values:

1.       Active

2.       Inactive

Note: An EOC Plan documents operations during an emergency, including the process to activate or inactivate the EOC.

Used In

HospitalStatus/Hospital/HospitalFacilityStatus

 

Element

<have:ClinicalStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The clinical status of the facility.

Comments

Values:

1.       Normal - Hospital clinical resources are operating within normal conditions.

2.       Full - Hospital clinical resources are exceeded and acceptable care cannot be provided to additional patients. Diversion or community surge response is required.

Used In

HospitalStatus/Hospital/HospitalFacilityStatus

 

Element

<have:DeconCapacity>

Type

xsd:string

Usage

OPTIONAL

Definition

The container element for Decon capacity.

Sub-elements

·         DeconCapacityStatus

·         AmbulatoryPatientsDeconCapacity

·         NonAmbulatoryPatientsDeconCapacity

Used In

HospitalStatus/Hospital/HospitalFacilityStatus

 

 

Element

<have:DeconCapacityStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The capacity for chemical/biological/radiological patient decontamination.

Comments

Values:

1.       Inactive - Not being used, but available if needed

2.       Open - In use and able to accept additional patients

3.       Full - In use at maximum capacity

4.       Exceeded - Needs exceed available capacity

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/DeconCapacity

 

Element

<have:AmbulatoryPatientsDeconCapacity>

Type

xsd:integer

Usage

OPTIONAL

Definition

The number of ambulatory patients which can be decontaminated over time (typically an hour).

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/DeconCapacity

 

Element

<have:NonAmbulatoryPatientsDeconCapacity>

Type

xsd:integer

Usage

OPTIONAL

Definition

The number of non-ambulatory patients which can be decontaminated over time (typically an hour).

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/DeconCapacity

 

Element

<have:MorgueCapacity>

Type

xsd:string

Usage

OPTIONAL

Definition

The status of the morgue capacity.

Sub-elements

·         MorgueCapacityStatus

·         MorgueCapacityUnits

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/DeconCapacity

 

Element

<have:MorgueCapacityStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The status of the morgue capacity.

Comments

Values:

1.       Open - Space is available

2.       Full - All normal space is in use

3.       Exceeded - Storage needs exceed available space

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/MorgueCapacity

 

Element

<have:MorgueCapacityUnits>

Type

xsd:integer

Usage

OPTIONAL

Definition

The number of vacant/available units to which victims can be immediately transported. 

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/MorgueCapacity

 

Element

<have:FacilityStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The status of the facility.

Comments

Values:

1.       Normal - No conditions exist that adversely affect the general operations of the facility.

2.       Compromised - General operations of the facility have been affected due to damage, operating on emergency backup systems, or facility contamination.

3.       Evacuating - Indicates that a hospital is in the process of a partial or full evacuation.  

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

HospitalStatus/Hospital/HospitalStatus/Hospital/HospitalFacilityStatus

 

Element

<have:SecurityStatus>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The status of security procedures in the hospital.

Comments

Values:

1.       Normal - The hospital is operating under routine security procedures.

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

3.       RestrictedAccess - Based on security needs, the hospital has activated procedures to allow access to the facility through a reduced number of controlled entrances.

4.       Lockdown - Based on security needs, the hospital has activated procedures to control entry to the facility to authorized persons only.

5.       Quarantine - Based on a public health emergency, the entry and exit of the facility is controlled by public health officials.

Used In

HospitalStatus/Hospital/HospitalFacilityStatus

 

Element

<have:Activity24Hr>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for reporting activities in the last 24 hours.  

Comments

1.       The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.

Sub-elements

·         Admissions

·         Discharges

·         Deaths

Used In

HospitalStatus/Hospital/HospitalFacilityStatus

 

Element

<have:Admissions>

Type

xsd:integer

Usage

OPTIONAL

Definition

The number of admissions in the last 24 hours.

Comments

1.       The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/Activity24Hr

 

Element

<have:Discharges>

Type

xsd:integer

Usage

OPTIONAL

Definition

The number of discharges in the last 24 hours.

Comments

1.       The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/Activity24Hr

 

Element

<have:Deaths>

Type

xsd:integer

Usage

OPTIONAL

Definition

The number of deaths in the last 24 hours.

Comments

1.       The time is relative to the timestamp of the <LastUpdateTime> of the <Hospital> element.

Used In

HospitalStatus/Hospital/HospitalFacilityStatus/Activity24Hr


3.2.7 HOSPITAL RESOURCES STATUS

 

Element

<have:HospitalResourcesStatus>

Type

XML Structure

Usage

OPTIONAL

Definition

The container for all the elements related to the operations of the facility.  

Sub-elements

·         Staffing

·         FacilityOperations

·         ClinicalOperations

·         ResourcesInformationText

·         CommentText

Used In

HospitalStatus/Hospital

 

Element

<have:Staffing>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The status of general staffing in the organization.  

Comments

Values:

1.       Adequate – Meets the current needs.

2.       Insufficient – Current need is not being met and impacts the operations of the hospital.

Note: Specific shortage in one or more departments should be noted in the comments.

Used In

HospitalStatus/Hospital/HospitalResourcesStatus

 

Element

<have:FacilityOperations>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The status of supplies necessary for facility operations.

Comments

Values:

1.       Adequate – Meets the current needs.

2.       Insufficient – Current needs are not being met.

Used In

HospitalStatus/Hospital/HospitalResourcesStatus

 

Element

<have:ClinicalOperations>

Type

xsd:string with restrictions

Usage

OPTIONAL

Definition

The status of supplies necessary for clinical operations.

Comments

Values:

1.       Adequate – Meets the current needs

2.       Insufficient – Current needs are not being met

Used In

HospitalStatus/Hospital/HospitalResourcesStatus

 

Element

<have:ResourcesInformationText>

Type

xsd:string; May use multiple

Usage

OPTIONAL

Definition

The type of resources and their status or count.

Constraints

1.       Multiple values are allowed and each resource type SHOULD be enclosed with a <ResourcesInformationText> element.

Comments

2.       This is an open format text field.

Ex:

<have:ResourcesInformationText> Ventilators - 40 are Available </have:ResourcesInformationText>

<have:ResourcesInformationText> Atropine - 20 Caches are Available </have:ResourcesInformationText>

Used In

HospitalStatus/Hospital/HospitalResourcesStatus


3.2.8 SUPPORTING ELEMENTS AND TYPES (Normative)

 

3.2.8.1 Elements

 

Element

<have:CommentText>

Type

xsd:string

Usage

OPTIONAL

Definition

Open Comments field. Unless otherwise specified, the <CommentText> field pertains to the element preceding it.

Comments

1.       There are no normative requirements imposed on the content of this element.  This element may contain any text that the creator of the document considers useful, and such text will be understood as referring to the element that precedes it, unless it explicitly references a different element in the EDXL-HAVE document.

Ex:

<have:DeconCapacity> Full <have:DeconCapacity>

<have:CommentText> We expect the capacity to be exceeded shortly <have:CommentText>

Note: In the above example, the <CommentText> pertains to the <DeconCapacity> element.

Used In

HospitalStatus/Hospital//Organization

HospitalStatus/Hospital/HospitalBedCapacityStatus/BedCapacity

HospitalStatus/Hospital/HospitalFacilityStatus

Hospital/HospitalResourcesStatus

HospitalStatus/Hospital/EmergencyDepartmentStatus

HospitalStatus/Hospital/ServiceCoverageStatus

 

 

Element

<have:LastUpdateTime>

Type

xsd:datetime

Usage

REQUIRED

Definition

The last time the information was updated.

Constraints

Each hospital element MUST have a <LastUpdateTime>

Used In

HospitalStatus/Hospital

 

3.2.8.2 TYPES

 

Type Name (normative)

TriageCount

Definition

The type of a container element for the number of each triage patient type the overall hospital currently has or that it can accept.

Sub-elements

·         TriageCodeListURN

·         TriageCode

Used In

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCensus

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSCapacity

 

 

Type Name (normative)

Offload

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

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSAmbulanceStatus

HospitalStatus/Hospital/EmergencyDepartmentStatus/EMSAirTransportStatus

 

3.2.8.3 geo-oasis Elements

 

Element

<gml: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

  1. The geo-coded address of the civil location.

<OrganizationGeoLocation>

<gml:Point>

<gml: pos>45.256 -71.92></gml: pos>

</gml:Point>

</OrganizationGeoLocation>

Note: See Appendix D for note on OASIS GML profile.

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/OrganizationGeoLocation

 

 

3.2.8.4 CIQ Elements

 

 

Element

<OrganisationName>

Type

xnl:OrganistionNameType

Usage

CONDITIONAL

Definition

The name of the Organization. Please refer to [OASIS CIQ]

Constraints

1.       Either the <OrganisationName> or the <OrganistionID> MUST be present.

Sub-elements

·         NameElement

·         SubDivisionName

Attribute

·         OrganisationID: A unique identifier for the Organization. Please refer to [OASIS CIQ]

 

1.       For the purposes of this document, <OrganisationID> is used to specify the identifier for the healthcare Organization.

Attribute

·         OrganisationIDType: The name of the provider that has provided the identification scheme. This could also be the name a particular identification list. Please refer to [OASIS CIQ]

 

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

Example: American Hospital Association

Constraints

1.       If <OrganisationID> is used, <OrganisationIDType> MUST be used.

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation

 

Element

<NameElement>

Type

xsd:string

Usage

OPTIONAL

Definition

Name of the Organization. Please refer to [OASIS CIQ]

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/OrganisationName

 

Element

<SubDivisionName>

Type

xsd:string

Usage

OPTIONAL

Definition

The name of the sub division Organization. Please refer to [OASIS CIQ]

Constraints

1.       <SubDivisionName> SHOULD be used if the reporting Organization has a parent Organization.

Comments

1.       If the <SubDivisionName> is used, the status being reported is that of the sub division Organization.

Example:

<xnl:OrganisationName>

<NameElement> ABC Hospital </NameElement>

<SubDivisionName> ABC Hospital at Location A </SubDivisionName>

</xnl:OrganisationName>

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/OrganisationName

 

Element

<OrganisationInfo>

Type

XML Structure

Usage

OPTIONAL

Definition

General details about the Organization.  Please refer to [OASIS CIQ]

Sub-elements

·         Type

·         OperatingHourStartTime

·         OperatingHourEndTime

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation

 

Element

<Type>

Type

xsd:string

Usage

OPTIONAL

Definition

Type of Organization. For purposes of EDXL HAVE standard, this could be hospital, nursing center, trauma center etc. Please refer to [OASIS CIQ]

Comments

1.       For purposes of EDXL HAVE standard, this could be hospital, nursing center, trauma center etc.

Example: Hospital, Nursing Center etc.

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/OrganisationInfo

 

Element

<OperatingHourStartTime>

Type

xsd:time

Usage

OPTIONAL 

Definition

Operating hour start time for the Organization ex: 09:00:00. Please refer to [OASIS CIQ]

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/OrganisationInfo

 

Element

<OperatingHourEndTime>

Type

xsd:time

Usage

OPTIONAL 

Definition

Operating hour end time for the Organization ex: 17:00:00. Please refer to [OASIS CIQ]

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/OrganisationInfo

 

Element

<Addresses>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for the specifying the address of the Organization. Please refer to [OASIS CIQ]

Sub-elements

·         HospitalStatus/Hospital/Address

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation

 

Element

<Address>

Type

xAL:AddressType

Usage

OPTIONAL

Definition

One or more addresses of the Organization. Please refer to [OASIS CIQ]

Constraints

1.       The geographic coordinates specified in <point> MUST match the address.

Comments

1.       For the purposes of the EDXL-HAVE specification, the below elements of the xAL: AddressType satisfy the usage requirements. .

2.       Use of the other sub elements of <Address> element other than the ones listed below is left to the choice of implementers, but care should be exercised as it can result in interoperability issues. 

Sub-elements

·         FreeTextAddress

·         Country

·         AdministrativeArea

·         PostCode

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses

 

Element

<FreeTextAddress>

Type

XML Structure

Usage

OPTIONAL

Definition

The container element for specifying the address in free text form. Please refer to [OASIS CIQ]

Sub-elements

·         AddressLine

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/Address

 

Element

<AddressLine>

Type

xsd:string

Usage

OPTIONAL; Multiple

Definition

One of the lines of the address of the Organization. If the address of the Organization consists of a single line, this element contains the entire address.  If the address consists of multiple lines, this element contains one of those lines. Please refer to [OASIS CIQ]

Comments

1.       Free format address representation. An address can have more than one line. The order of the <xAL: AddressLine> elements needs to be preserved.

Used In

HospitalStatus/Hospital/

Organization/OrganizationInformation/Addresses/Address/FreeTextAddress

 

Element

<Country>

Type

xAL:CountryType

Usage

OPTIONAL

Definition

The details of the country. Please refer to [OASIS CIQ]

Sub-elements

·         NameElement

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/Address

 

Element

<AdministrativeArea>

Type

XML Structure

Usage

OPTIONAL

Definition

Details of the top level area division in the country. Ex: State, District, Province etc. Please refer to [OASIS CIQ].

Sub-elements

·         NameElement

·         SubAdministrativeArea

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/Address

 

Element

<SubAdministrativeArea>

Type

XML Structure

Usage

OPTIONAL

Definition

The next level of sub-division of the area. Ex: county etc. Please refer to [OASIS CIQ].

Sub-elements

·         NameElement

Used In

HospitalStatus/Hospital/

Organization/OrganizationInformation/Addresses/Address/AdministrativeArea

 

Element

<PostCode>

Type

XML Structure

Usage

OPTIONAL

Definition

A container for a single free text or structured post code. Please refer to [OASIS CIQ]

Sub-elements

·         Identifier

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/Address

 

Element

<Identifier>

Type

xAL:IdentifierType

Usage

OPTIONAL

Definition

The post code is formatted to country-specific rules. Ex: SW3 0A8-1A, 600074, 2067 etc. Please refer to [OASIS CIQ]

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/Address/PostCode

 

Example 1:

<a:Address>

   <a:FreeTextAddress>

          <a:AddressLine>P O Box 455</a:AddressLine>

          <a:AddressLine >Billerica, MA 01821</a:AddressLine >

   </a:FreeTextAddress>

</a:Address>

 

Example 2:

<a:Address>

   <a: Country>USA</Country>

   <a:AdministrativeArea>

          <a:NameElement>MA</a:NameElement>

   </a:AdministrativeArea>

   <a:SubAdministrativeArea>

          <a:NameElement>Billerica</a:NameElement>

   </a:SubAdministrativeArea>

   <PostCode>01821</PostCode>

</a:Address>

 

 

Element

<ContactNumbers>

Type

XML Structure

Usage

OPTIONAL

Definition

All kinds of communication lines used for contact purposes. Ex:. phone, fax, mobile, pager, etc. Please refer to [OASIS CIQ]

Sub-elements

·         ContactNumber

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation

 

Element

<ContactNumber>

Type

XML Structure

Usage

OPTIONAL

Definition

Universal telecommunication number structure. Please refer to [OASIS CIQ]

Comments

1.       The attributes of this element carry important information about the contact number (see [OASIS CIQ], Sec 6.2.4).

Attributes

·         CommunicationMediaType

·         ContactHours

Used In

HospitalStatus/Hospital/Organization/OrganizationInformation/ContactNumbers

 

Example – Contact Phone Number

 

<p:ContactNumber p:CommunicationMediaType="Telephone" p:ContactHours="9:00AM - 5:00PM">

   <p:ContactNumberElement p:ElementType="CountryCode">61</p:ContactNumberElement>

   <p:ContactNumberElement p:ElementType="AreaCode">2</p:ContactNumberElement>

   <p:ContactNumberElement p:ElementType="LocalNumber">94338765</p:ContactNumberElement>

</p:ContactNumber>

 

 

 

 

 

 

 

 

 

4.1 CONFORMANCE TARGETS

 

The two following conformance targets are defined in order to support the specification of conformance to this standard:

 

a)       EDXL-HAVE Report;

 

b)       EDXL-HAVE Report Producer.

 

An EDXL-HAVE Report is an XML 1.0 document whose syntax and semantics are specified in this standard.  An EDXL-HAVE Report Producer is a software entity that produces EDXL-HAVE reports.

 

NOTE – There is no conformance target corresponding to the consumers of EDXL-HAVE reports because this standard does not specify any requirements that apply specifically to them.

 

 

4.2 CONFORMANCE AS AN EDXL-HAVE REPORT

 

An XML 1.0 document is a conforming EDXL-HAVE Report if and only if:

 

a)       it is valid according to the schema located at http://docs.oasis-open.org/emergency/edxl-have/v1.0/edxl-have.xsd; and

 

b)       the content of its elements and the values of its attributes meet all the additional mandatory requirements specified in section 3.

 

4.3 CONFORMANCE AS AN EDXL-HAVE REPORT PRODUCER

 

A software entity is a conforming EDXL-HAVE Report Producer if and only if:

 

it is constructed in such a way that any XML document produced by it and present in a place in which a conforming EDXL-HAVE Report is expected (based on contextual information) is indeed a conforming EDXL-HAVE Report according to this standard.

 

The condition in (1) above can be satisfied in many different ways. Here are some examples of possible scenarios:

·         a standard protocol (say, EDXL-DE) transfers messages carrying EDXL-HAVE reports; a client has sent a request for an EDXL-HAVE report to a server which claims to be a conforming EDXL-HAVE Report Producer, and has received a response which is therefore expected to carry a conforming EDXL-HAVE Report;

·         a local test environment has been set up, and the application under test (which claims to be a conforming EDXL-HAVE Report Producer) has the ability to produce a EDXL-HAVE report and write it to a file in a directory in response to a request coming from the testing tool; the testing tool has sent many requests to the application under test and is now verifying all the files present in the directory, which is expected to contain only conforming EDXL-HAVE Reports;

·         an EDXL-HAVE Report is attached to an email message which, according to a prior agreement between sender and recipients, is expected to carry a conforming EDXL-HAVE Report as an attachment;

·         an EDXL-HAVE Report has been published at a location on the World Wide Web from where it can be retrieved by an authorized person by using the HTTP protocol, and the producer has created the expectation that that location will contain a conforming EDXL-HAVE Report.


A.   EDXL-HAVE EXAMPLE (NON-NORMATIVE)

Note: The example shown below is for informative purposes only – to illustrate the content. An actual XML sample will be contained in EDXL-DE or similar routing block structure.

 

<?xml version="1.0" encoding="UTF-8"?>

<have:HospitalStatus xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:HAVE:1.0 edxl-have_cs01.xsd" xmlns="urn:oasis:names:tc:emergency:EDXL:HAVE:1.0" xmlns:n3="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xal="urn:oasis:names:tc:ciq:xal:3" xmlns:xnl="urn:oasis:names:tc:ciq:xnl:3" xmlns:xpil="urn:oasis:names:tc:ciq:xpil:3">

 

<have:Hospital>

 

 <have:Organization>

  <have:OrganizationInformation>

   <xnl:OrganisationName>

    <xnl:NameElement>ABC Hospital</xnl:NameElement>

   </xnl:OrganisationName>

<xpil:OrganisationInfo xpil:Type="Hospital"                           xpil:OperatingHourStartTime="09:00:00.0Z"       xpil:OperatingHourEndTime="18:00:00.0Z"/>

   <xpil:Addresses>

   <xpil:Address>

     <xal:FreeTextAddress>

      <xal:AddressLine>

P O Box 455, Billerica, MA 0182, USA

      </xal:AddressLine>

     </xal:FreeTextAddress>

    </xpil:Address>

   </xpil:Addresses>

  </OrganizationInformation>

  <OrganizationGeoLocation>

   <gml:Point>

    <gml:pos>3.14159265358979E0</gml:pos>

   </gml:Point>

  </have:OrganizationGeoLocation>

 </have:Organization>

 

 

 <have:EmergencyDepartmentStatus>

  <have:EMSTraffic>

   <have:EMSTrafficStatus>Normal</have:EMSTrafficStatus>

  </have:EMSTraffic>

  <have:EMSCapacity>

   <have:TriageCount>

    <have:TriageCodeListURN> oasis:names:tc:emergency:have:1.0:triagecolorcode

   </have:TriageCodeListURN>

   <have:TriageCode>

    <have:TriageCodeValue>Red</have:TriageCodeValue>

    <have:TriageCountQuantity>20</have:TriageCountQuantity>

   </have:TriageCode>

   <have:TriageCode>

    <have:TriageCodeValue>Yellow</have:TriageCodeValue>

    <have:TriageCountQuantity>30</have:TriageCountQuantity>

   </have:TriageCode>

   <have:TriageCode>

    <have:TriageCodeValue>Green</have:TriageCodeValue>

    <have:TriageCountQuantity>40</have:TriageCountQuantity>

   </have:TriageCode>

   <have:TriageCode>

    <have:TriageCodeValue>Black</have:TriageCodeValue>

    <have:TriageCountQuantity>10</have:TriageCountQuantity>

    </have:TriageCode>

   </have:TriageCount></have:EMSCapacity>

  <have:EMSAmbulanceStatus>

   <have:Offload>

 <have:EMSOffloadStatus>Normal</have:EMSOffloadStatus>

  <have:EMSOffloadMinutes>20</have:EMSOffloadMinutes>

 </have:Offload>

  </have:EMSAmbulanceStatus>

 </have:EmergencyDepartmentStatus>

 

<have:HospitalBedCapacityStatus>

 <have:BedCapacity>

  <have:BedType>AdultICU</have:BedType>

  <have:Capacity>

   <have:CapacityStatus>Vacant/Available</have:CapacityStatus>

   <have:AvailableCount>40</have:AvailableCount>

   <have:BaselineCount>60</have:BaselineCount>

  </have:Capacity>

 </have:BedCapacity>

 

 <have:BedCapacity>

  <have:BedType>Burn</have:BedType>

   <have:Capacity>

    <have:CapacityStatus>Vacant/Available</have:CapacityStatus>

    <have:AvailableCount>30</have:AvailableCount>

   <have:BaselineCount>50</have:BaselineCount>

  </have:Capacity>

 </have:BedCapacity>

 

<have:BedCapacity>

 <have:BedType>MedicalSurgical</have:BedType>

  <have:Capacity>

   <have:CapacityStatus>Vacant/Available</have:CapacityStatus>

   <have:AvailableCount>20</have:AvailableCount>

   <have:BaselineCount>30</have:BaselineCount>

  </have:Capacity>

 </have:BedCapacity>

</have:HospitalBedCapacityStatus>

 

 

<have:ServiceCoverageStatus>

 <have:Burn>true</have:Burn>

 

 <have:CardiologyIndicator>

  <have:Cardiology>true</have:Cardiology>

 </have:CardiologyIndicator>

 

 <have:Dialysis>true</have:Dialysis>

 <have:EmergencyDepartment>true</have:EmergencyDepartment>

 <have:HyperbaricChamber>false</have:HyperbaricChamber>

 <have:InfectiousDisease>false</have:InfectiousDisease>

 <have:Neonatology>true</have:Neonatology>

 

 <have:NeurologyIndicator>

  <have:Neurology>true</have:Neurology>

 </have:NeurologyIndicator>

 <have:OBGYNIndicator>

  <have:OBGYN>true</have:OBGYN>

 </have:OBGYNIndicator>

 

 <have:Ophthalmology>true</have:Ophthalmology>

 <have:Orthopedic>true</have:Orthopedic>

 <have:Pediatrics>text</have:Pediatrics>

 

 <have:PsychiatricIndicator>

  <have:Psychiatric>true</have:Psychiatric>

 </have:PsychiatricIndicator>

 

 <have:SurgeryIndicator>

  <have:SurgerySubType>

    <have:AdultGeneralSugery>true</have:AdultGeneralSugery>

    <have:CardioThoracic>true</have:CardioThoracic>

   </have:SurgerySubType>

  </have:SurgeryIndicator>

 

 <have:TransportServicesIndicator>

  <have:TransportServices>true</have:TransportServices>

 </have:TransportServicesIndicator>

 

 <have:TraumaCenterServicesIndicator>

  <have:TraumaCenterServices>true</have:TraumaCenterServices>

  <have:TraumaCenterServicesLevel>Level2</have:TraumaCenterServicesLevel>

 </have:TraumaCenterServicesIndicator>

</have:ServiceCoverageStatus>

 

 

<have:HospitalFacilityStatus>

 <have:ClinicalStatus>Normal</have:ClinicalStatus>

 <have:FacilityStatus>Normal</have:FacilityStatus>

 <have:SecurityStatus>Normal</have:SecurityStatus>

</have:HospitalFacilityStatus>

 

 

 

<have:HospitalResourcesStatus>

 <have:Staffing>Adequate</have:Staffing>

 <have:FacilityOperations>Adequate</have:FacilityOperations>

 <have:ClinicalOperations>Adequate</have:ClinicalOperations>

 <have:ResourcesInformationText>

  20 ventilators are available

 </have:ResourcesInformationText>

 <have:ResourcesInformationText>

  Atropine - 20 caches are available

 </have:ResourcesInformationText>

</have:HospitalResourcesStatus>

 

 

 <have:LastUpdateTime>2001-12-17T09:30:47.0Z</have:LastUpdateTime>

 

 

</have:Hospital>

 

 

</have:HospitalStatus>

 

Note: The definitions are used from the HAvBED report [HAvBED Report].

These standardized definitions were vetted by a working group assembled by Denver Health with members from Federal and State governments, hospitals around the nation, and the private sector in the United States of America.

Hospital Bed Definitions

 

Vacant/Available Beds refers to beds that are vacant and to which patients can be immediately transported. 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.

 

 

 

 

 

A description of the types of beds includes the following:

 

     Adult Intensive Care (ICU): beds that can support critically ill/injured patients, including ventilator support

 

     Medical/Surgical: also thought of as “Ward” beds

 

     Burn: 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.)

 

     Pediatric ICU: as for Adult ICU, but for patients 17 years and younger

 

     Pediatrics: “Ward Medical/Surgical” beds for patients 17 and younger

 

     Psychiatric: “ward” beds on a closed/locked psychiatric unit or ward beds where a patient will be attended by a sitter.

 

     Negative Pressure/Isolation: - Beds provided with negative airflow, providing respiratory isolation. NOTE: This value may represent available beds included in the counts of other types.

 

     Operating Rooms: – An operating room that is equipped and staffed and could be made available for patient care in a short period of time.

 

 

 

Bed Availability Definitions

 

 

The bed availability estimates are defined as below:

 

·        24 hr Beds Available: This value represents an informed estimate as to how many vacant (staffed, unoccupied) beds for each bed type above the current number that could be made available within 24 hours.  This would include created institutional surge beds as well as beds made available by discharging/transferring patients.

·        72 hr Beds Available: This value represents an informed estimate as to how many vacant (staffed, unoccupied) beds for each bed type above the current number that could be made available within 72 hours.  This would include created institutional surge beds as well as beds made available by discharging/transferring patients.

 

 

CIQ Overview

 

The objective of the OASIS CIQ TC is to deliver a set of XML Specifications for defining, representing, interoperating and managing party information (e.g. name, address, party specific information including party relationships) that are truly open, vendor neutral, industry and application independent, and importantly "Global" (ability to represent international data formats such as different types of party names and addresses used in 241+ countries).

 

The CIQ TC’s XML Name, Address and Party languages (version 3.0) define universal structures for name, address entities, party, and party relationship entities. It consists of the following components:

Note: This section only provides a brief overview and includes a subset – that is relevant to EDXL-HAVE- of the CIQ specification. The purpose is to provide an overview – users are encouraged to look at the OASIS CIQ TC website for complete information - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq

 

Name

Description

xNL

extensible Name Language

 

xNL defines an XML format to represent party name information. A party name could be a “Person” or an “Organization”. An “Organization” could be educational institutions like school, university, college, etc, clubs, associations, industry groups, not-for-profit bodies, consortiums, user groups, etc.

xAL

extensible Address Language

xAL defines an XML format to represent address data. It includes: hospitals, airports, businesses, educational institutions etc.

xPIL

extensible Party Information Language

xPIL defines XML specifications to represent party centric data. Party centric data includes:

• Address, E-mail address, URL, Contact numbers (Mobile, Pager, Fax, Landline, etc)

 

 

CIQ Usage in EDXL-HAVE

 

EDXL HAVE uses Party information (xPIL) in the CIQ specifications for its naming and address requirements. For the purposes of HAVE, the naming and location elements (street address) elements are used. The use of other elements is left to implementation choices.

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

 

Participants

 

·         Alessandro Triglia, OSS Nokalva

·         Aviv Siegel, Athoc, Inc.

·         Elysa Jones, Warning Systems, Inc.

·         Renato Iannella, NICTA

·         Richard Vandame, US Dept of Homeland Security

·         Harry Haury, NuParadigm Government Systems, Inc.

·         Paul Thorpe, OSS Nokalva

·         Jeff Kyser, Warning Systems, Inc.

·         Lee Tincher, Evolution Technologies Inc

·         David Kehrlein, ESRI

·         Jack Fox, US Department of Homeland Security

·         Sukumar Dwarkanath, Associate Member

·         Gary Ham, Associate Member

·         Mark Pleimann, Mitre Corporation

·         Shane Rimmer, ESI Acquisition, Inc.

·         Ron Lake, Galdos Systems

·         Carl Reed, Open Geospatial Consortium, Inc.

·         Enoch Moses, ManTech Enterprise Integration Center

·         David Danko, ESRI

·         Tom Wall, Evolution Technologies

·         David Lamendsdorf, Emergency Interoperability Consortium

·         Karen Robinson, NICTA

·         Olivier Dubuisson, France Telecom

·         Rex Brooks, Individual

·         Werner Joerg, IEM

·         Tim Grapes, Evolution Technologies

·         Tom Merkle, Lockheed Martin

·         Bryan Small, ESI Acquisition, Inc.

·         Anthony Sangha, Raining Data Corporation

·         Tracy Ryan, Emergency Interoperability Consortium

·         Judith Woodhall, COMCARE

·         Adam Hocek, Associate Member

·         Josh Shows, ESI Acquisition, Inc.

·         David Ellis, Sandia National Laboratories

·         Yohannes Tilahun, Associate Member

·         Sylvia Webb, Individual

·         Mark Carlson, Associate Member

·         Kurt Buehler, Associate Member

 

Revision

Date

Editor

Changes Made

Public Review Version 05

04 March 2008

Sukumar Dwarkanath

·         Changed document status to ‘Public Review Draft 05’

Public Review Version 4

Revision 01

29 February 2008

Sukumar Dwarkanath

·         Deleted non-UTF character (‘) in schema – changed from ‘Available’ to Available in schema documentation.

·         Corrected typo in schema – changed AmubulatoryPatientsDeconCapacity to AmbulatoryPatientsDeconCapacity

Public Review Version 4

08 February 2008

Sukumar Dwarkanath

·         Changed document name and status to ‘Public Review Draft 04’

Public Review Version 3 Revision 02

06 February 2008

Sukumar Dwarkanath

·         Schema: Modified element ‘MorgueCapacityStatus to be of type ‘xsd: string with restrictions; enumerations include ‘Open’, ‘Full’ and ‘Exceeded’

·         Schema: Corrected typo: ‘AdultGeneralSurgery’

Public Review Version 3 Revision 01

30 January 2008

Sukumar Dwarkanath

·         Modified schema to change imported file from “xpil.xsd” to “xPIL.xsd”

·         Changed [namespaces] reference to “T. Bray et al”

·         Changed [XML 1.0] reference to “T. Bray et al”; changed link to “http://www.w3.org/TR/REC-xml/

·         Replaced [dateTime] reference with “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"

·         Modified examples to include namespaces

Public Review  Version 3

10 October 2007

Sukumar Dwarkanath

·         Included Conformance section as per OASIS guidelines

·         Made changes following internal TC review. These changes are highlighted here in: http://www.oasis-open.org/committees/document.php?document_id=25471&wg_abbrev=emergency

Public Review Version 3.0

29 June 2007

Sukumar Dwarkanath

·         Made changes following the public review period. These changes are highlighted in the EDXL HAVE Issues List v4.2 - http://www.oasis-open.org/committees/download.php/24513/EDXL_HAVE_IssuesList_v4.3.xls

Public Review Version 2.0

13 November 2006

Sukumar Dwarkanath

·         Changed document status from ‘Public Review Draft 1.0 Revision 01’ to ‘Public Review Draft 2.0’

·         Changed approval date to ’02 November 2006’

Public Review Version 1.0 Revision 01

23 October 2006

Sukumar Dwarkanath

·         Changed datatype of <LocationPostalCodeID> from ‘Integer’ to ‘String’

·         Changed Cardinality of Capacity element from ‘0 to *’ to ‘0 to 1’; modified DOM to reflect changes

·         Renamed <Bed> to <BedType>

·         Renamed <SubCategoryBed> to <SubCategoryBedType>

·         Removed Maximum limit enumeration  – 60 Mts – from <EMSOffloadMinutes>

·         Changed datatype of <ServiceCoverageStatus> element to xsd:boolean type

·         Changed datatype of Surgery element to xsd:boolean

·         Replaced OGC GML Profile schema with new version of schema; replaced schema diagram

·         Modified EDXL-HAVE schema; modified EDXL-HAVE example

·         Formatted document to be consistent with OASIS template

·         Added metadata - This Version and Previous version; corrected IPR Policy note – changed year from ‘2005’ to ‘2006’; corrected IPR note – Changed ‘wsrf’ to ‘emergency’; removed Organization affiliation from Editor Name; corrected numbering of sections 3.2.6 and 3.2.7; added Non-normative changes; removed Corporate Affiliations from List of Associate Members in Appendix; modified key word list.

·         Added Revision History Table

·         Formatted element names, datatype, and parent elements.

·         Renamed appendix C.1 - geo-oasis ELEMENTS