1 Introduction

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 its facility and operations.

[All text is normative unless otherwise labeled]

1.0 IPR Policy

This Committee Specification Public Review Draft is provided under the RF on RAND Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established.

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

1.1 Terminology

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

1.2 Normative References

NOTE: Many of these references are used as or in relation to imported schema for the Normative XML Schema for EDXL-HAVE-v2.0 available separately: http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd02/schemas/edxl-have-v2.0.xsd. (See “Additional artifacts” on front page.)

[XMLSCHEMA-2]
XML Schema Part 2: Datatypes Second Edition, P. V. Biron, A. Malhotra, Editors, W3C Recommendation. http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ Latest version available at http://www.w3.org/TR/xmlschema-2/.

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

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

[XML-NAMES]
Namespaces in XML 1.0 (Third Edition), T. Bray, D. Hollander, A. Layman, R. Tobin, H. S. Thompson, Editors, W3C Recommendation. 8 December 2009. http://www.w3.org/TR/2009/REC-xml-names-20091208/ . Latest version available at http://www.w3.org/TR/xml-names.

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

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

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

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

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

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. Bradner, S. BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.

[RFC5646]
Tags for Identifying Languages, Phillips, A., Ed., and M. Davis, Ed., BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, http://www.rfc-editor.org/info/rfc5646.

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

[XML 1.0]
Extensible Markup Language (XML) 1.0 (Fifth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, Editors, W3C Recommendation. 26 November 2008. http://www.w3.org/TR/2008/REC-xml-20081126/ . Latest version available at http://www.w3.org/TR/xml.

1.3 Non-Normative References

NOTE: Many references contain element names, definitions and resource materials that were used in the development of this specification whether or not such material is cited as such in the text.

[AHIC-BIODATA]
BioSurvellience Data Elements. American Health Information Community (AHIC), BioSurvellience Data Working Group.

[EDXL-DE]
EDXL Distribution Element (DE) Standard v1.0. March 2006. OASIS. http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc.

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

[GJXDM]
Global Justice XML Data Model (GJXDM) Data Dictionary. Global, Office of Justice Programs. http://it.ojp.gov/default.aspx?area=nationalInitiatives&page=1013

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

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

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

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

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

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

[NIEM]
National Information Exchange Model. https://it.ojp.gov/initiatives/niem.

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

1.4 Purpose

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

The current roster of published EDXL Standards includes:

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

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

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

1.5 History

In a disaster or emergency situation, there is a need for hospitals to be able to communicate with each other, and with other members of the emergency response community. The ability to exchange data in regard to hospitals’ bed availability, status, services, and capacity enables both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiency and speed. In particular, it will allow emergency dispatchers and managers to make sound logistics decisions such as where to route victims and automatically determining 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 Emergency Operations Centers (EOCs), 9-1-1 centers, and Emergency Medical Systems (EMS) responders via a Web-based tool.

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

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

The HAVE data exchange standard goes hand in hand with the EDXL Tracking of Emergency Patients (TEP). A TEP-based data exchange collects data on patients from incident EMS first encounter and field hospital triage to EMS transport and patient registration at a definitive care facility such as a hospital emergency room. It can also be used for the routine transport of patients and for the evacuation of hospitals involving EMS transport and care. In all scenarios, it relieves the heavy administrative burden levied on staff to re-key patient information, often after the fact, enabling automatic and pro-active hospital preparedness. In September of 2016, a bidirectional transformation specification between TEP and HL7 messaging was completed. This enables the transformation of the TEP data taken by emergency response to automatically populate in hospital data systems.

HAVE supports the TEP standard by providing the data needed about available hospital resources to enable the informed routing decisions needed by EMS. In this way, the patients can be routed to the hospital with the facilities needed to support their needs. Given the TEP, the emergency room will be able to see the data about the incoming patient in order to best prepare for their optimal care. Both of these initiatives began with the Department of Homeland Security Science and Technology (DHS S&T) effort to identify the next most important data standards needed for emergency response. Practitioners in both the medical and emergency management domains were included in developing draft specifications after many facilitated sessions to include scenario working groups.

The National Association of Emergency Medical Services Officials (NASEMSO) is one organization that participated in the DHS S&T effort. In October 2015, NASEMSO issued a resolution to encourage the completion and implementation of the TEP and HAVE standards.

The DHS S&T effort concluded with two live exercises utilizing both TEP and HAVE (see next section).

The HAVE 2.0 will be coordinated with HL7 through the work of the Patient Administration Work Group. OASIS and HL7 intend to release a joint specification for the HAVE Standard under the Statement of Understanding between the organizations. The effective exchange and common data interoperability will enable both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiently and speed.

The TEP and HAVE Standards Have Been Proven Successful in Live Exercises

The draft TEP standard was successfully implemented by four independent systems: Tennessee’s state EMS system and a local EMS system in Memphis, the state of Maryland EMS system, and the federal JPATS system. The Integrated Public Alerts and Warnings System (IPAWS) was plugged in as the message broker (the “post office” that routes data traffic where users need). State, local and federal agencies proved that these standards-based data exchanged work by plugging into existing major live-actor patient movement exercises at disaster sites, aircraft bases and hospitals.

During a 2010 National Disaster Medical System (NDMS) patient movement exercise in Tennessee, data following patient movement from Maryland to Tennessee was exchanged in real time between the Maryland EMS system to JPATS then to the Tennessee State and Memphis EMS systems. All systems displayed the current data as if updates were completed directly in their system. EM Systems was used to compile and aggregate HAVE data from 3 different hospitals, which was used by emergency managers to route patients to the most appropriate destinations with the availability, capabilities and staff to provide care.
Simultaneously with the FEMA National Level Exercise (NLE) in 2011, five states cooperated to track patient movement across them employing five different patient tracking systems. All systems, some commercially available and some home-grown, were able to track the data updates in their own systems.

At the 2012 Integrated Medical, Public Health, Preparedness and Response Training Summit, presenters from the DHS S&T Practitioner Steering Group moved volunteer patients through the room to different “states” and were able to display data updates across four independent systems including JPATS.

In these exercises and the 2012 demonstration, as each existing system automatically scanned, entered or updated patient data, that data was automatically shared in near real-time behind the scenes with no manual intervention, allowing users to view and report data in their own systems as if all data updates were made there. Using an aggregation of multiple hospital HAVE reports, emergency managers were able to route patients to appropriate destinations.

1.6 Structure of the EDXL Hospital Availability Exchange Specification

The EDXL-HAVE 2.0 standard document structure is defined using successively more detailed or constrained artifacts in the form of textual descriptions, diagrams, figures, tables and Appendices. The EDXL-HAVE XML Schema is provided separately. The overall structure of the EDXL-HAVE report is first represented in an Element Reference Model (ERM). The ERM is the foundation from which individual constraint schemas (individual situation report types) are defined.

The structure of the EDXL-HAVE standard is defined in the following sections:

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

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

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

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

cardinality.

2 Design Principles & Concepts (non-normative)

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

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

2.1 Requirements for Design

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

Figure 1 - EM EDXL-HAVE SC Scope

2.2 Example Usage Scenarios

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

2.2.1 Day-to-Day – Dialysis Patient:

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

2.2.2 First Responder – Responding with Critical Care

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

2.2.3 Mass-Scale Vaccination Clinics

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

2.2.4 Disaster Response:

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

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

3 EDXL HAVE

Section 3 of this Standard is normative unless otherwise stated. If any differences are found between any XML schema and its associated model, diagram, table or other artifact or text, then the XML schema shall always take precedence and the other artifact(s) must be changed to match the XML schema.

Note: Please report any such errors to OASIS.

3.1 HAVE Report Definition (non-normative)

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

Typical actors:

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

3.2 Supporting Elements (non-normative)

3.2.1 Common Types

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

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

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

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

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

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

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

3.2.2 Selecting Values from Lists

The ValueList and ValueKey types are part of the EDXL Common Types collection. They allow standards adopters to use topic specific lists of values for elements such as externalCode alternateCodeValue, etc.. Both types have identical structure, but ValueList allows for selection of multiple values [1..*] in the list, whereas ValueKey allows for selection of only one [1..1] value in the list.

When using a ValueList / ValueKey structure the user can specify a user-defined list by URI (either using the “urn:...” format or the more familiar “http://...” format) and then include user-defined values from that list. This structure has several advantages: (a) it provides flexibility for local communities to use community-defined terms and vocabulary; (b) it allows for the external maintenance of local or standardized lists; and (c) it avoids the problems inherent in attempting to constantly update hard-coded enumerations in a specification.

An existing vetted list should be referenced for defaults, but users could also reference their own value list

3.2.3 ValueKeyType

The schema for ValueKeyType is defined as

<xs:complexType name="ValueKeyType">

<xs:sequence>

<xs:element ref="ct:ValueListURI" minOccurs="1" maxOccurs="1"/>

<xs:element ref="ct:Value" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

and its application to the XML description of an element elementName of type ct:ValueKeyType would be:

<elementName>

<ct:ValueListURI>valueListURI</ct:ValueListURI>

<ct:Value>value</ct:Value>

</elementName>

This example uses a published list of values and definitions and selects one specific entry to describe a resource need of a facility:

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

which stands for

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

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

</resourceKind>

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

3.2.4 EDXL Extensions

HAVE 2.0 supports supplemental inclusion of community-defined sets of name/value pairs, referred to here as “Community Extensions” or simply “Extensions” for short. For example, the HAVE Status element contains a stability field, which indicates if the status is stable, improving, or deteriorating. The “Extension” concept would allow a sender to augment this information with a qualifier, such as “rapidly” or “slowing”, providing finer grain detail on the situation. The “Community Extensions” concept solves several major problems for improving information sharing and developing standards for the emergency management community. First, the nature of emergencies is that the unexpected will happen and emergency managers need flexibility to send whatever information is needed. Second, an emergency begins and often stays local, so local authorities and users need control to send the information they decide is important to address the current emergency. Third, communities need the opportunity to explore potential new standards. The parameter name/value extension mechanism, along with the registration and best practice guidance, provides an on-ramp for communities to determine what works well for them. The Community Extensions that are most successful can be incorporated formally into future standards.

Typical needs are:

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

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

ServiceType
ResourceInformationType
OperationType
OffloadInfoType
TraumaCenterLevelType

The schema for Extension is defined as

<xs:element name="extension">

<xs:complexType>

<xs:sequence>

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

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

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<extension>

<community>communityURI</community>

<id>idURI</id>

<parameter>

<nameURI>nameURI</nameURI>

<value>some value</value>

</parameter>

</extension>

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

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

which stands for

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

<id>extension:1</id>

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

<value>Rapidly</value>

</parameter>

</extension>

3.4 Distribution of EDXL-HAVE (non-normative)

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

3.5 HAVE Elements

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

· facility name and location,

· overall facility status, ..

· services, ..

· operations, ..

· resources, ..

· staffing, ..

· and emergency department.

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

4 Data Dictionary

This Data Dictionary specifically references the document EDXL_HAVE_Requirements_12232005 publicly available at https://www.oasis-open.org/committees/document.php?document_id=16400&wg_abbrev=emergency This is the source to which the ‘Requirements Supported’ row in each element entry refers. Since the Requirements are numbered, we cite the Requirement number that the entry supports.

4.1.1 HAVE

Element	HAVE
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Top Level item for Hospital AVailability Exchange (HAVE) message.
Comments	· Provides context to the HAVE report
Sub-elements	· organizationInformation · reportingPeriod · facility · remarks
Requirements Supported	Requirement Number 1.

Element	organizationInformation
Type	OrganizationInformationType [xpil:OrganisationDetailsType]
Usage	REQUIRED, MUST be used once and only once
Definition	Information of the Organization that is responsible for the reporting of these facilities.
Comments	· Based on [xpil:OrganisationDetailsType]
Constraints	Specific information includes: · OrganisationName · Addresses · ContactNumbers · ElectronicAddressIdentifiers · OrganisationInfo
Requirements Supported	Requirement Numbers 1, 2.

Element	reportingPeriod
Type	edxl-ct:TimePeriodType
Usage	OPTIONAL, MAY be used once and only once
Definition	The reporting period applicable for the HAVE root element and called the "current reporting period" typically a 24-hr period but the duration may change for operational reasons. If blank the assumption is that the file is for "today" - local to the issuer.
Comments	·
Constraints	Must use · fromDateTime · toDateTime
Requirements Supported	Requirement Numbers 1, 8.

Element	facility
Type	FacilityType
Usage	REQUIRED, MAY be used more than once
Definition	A list of facilities that comprise the detail of this HAVE message.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used more than once
Definition	Provides context to the HAVE report.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19.

Attribute	defaultLanguage
Type	xs:string
Usage	REQUIRED, MUST be used once and only once
Definition	Tag specifying the language that is used throughout the document. Tag MUST comply RFC3066. Free text within the document will be assumed to be in this defaultLanguage. Example: “en_US”
Comments	·
Constraints	·
Requirements Supported	Requirement Number 1.

4.1.2 FacilityType

Element	FacilityType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once.
Definition	The set of information details that define a facility..
Comment	·
Sub-elements	· name · kind · reportingPeriod · lastUpdate · organizationInformation · geoLocation · status · services · futureServices · activityInPeriod · operations · resourceInformation · staffing · emergencyDepartment · traumaCenter · remarks
Requirements Supported	Requirement Numbers 1, 3.

Element	name
Type	FreeTextType [LimitedString (restriction base: xs:string)]
Usage	REQUIRED, MUST be used once and only once
Definition	Name of facility.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3.

Element	kind
Type	FacilityKindType
Usage	REQUIRED, MUST be used once and only once
Definition	The kind of facility (e.g. Hospital, Long Term Care, Seniors Residence, Temporary Clinic).
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3.

Element	reportingPeriod
Type	edxl-ct:TimePeriodType
Usage	OPTIONAL, MAY be used once and only once
Definition	The reporting period applicable for this Facility element and the "current reporting period" typically a 24-hr period but the duration may change for operational reasons. If this value is not provided the HAVE message reporting period will be assumed.
Comments	·
Constraints	Must use · fromDateTime · toDateTime
Requirements Supported	Requirement Numbers 1, 8.

Element	lastUpdate
Type	edxl-ct:EDXLDateTimeType
Usage	OPTIONAL, MAY be used once and only once
Definition	The reporting period applicable for this HAVE report and called the "current reporting period" typically a 24-hr period but the duration may change for operational reasons. If blank the assumption is that the file is for "today" - local to the issuer
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 8.

Element	organizationInformation
Type	xpil:OrganisationDetailsType
Usage	REQUIRED, MUST be used once and only once
Definition	Administrative and Organizational information about the Facility.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2.

Element	geoLocation
Type	GeoLocationType (restriction base: edxl-gsf:EDXLGeoLocationType)
Usage	REQUIRED, MUST be used once and only once
Definition	The single geometry that represents the Facility location. A WGS84 SRS element is mandatory. Alternate SRS geometry elements can be provided. If alternate geometry elements are provided they should reflect the same physical location.
Comments	· MUST include a <wgs84Location> element · SRS attribute MUST be “http://www.opengis.net/def/crs/EPSG/0/4326”. · MAY include one or more <geoLocationExtended> elements.
Constraints	·
Requirements Supported	Requirement Numbers 1, 10.

Element	status
Type	StatusType
Usage	REQUIRED, MUST be used once and only once
Definition	The overall status of the Facility. This value is intended to provide a high-level summary status of the Facility from the perspective of the person responsible for the Facility. The particulars driving that Facility status should be provided where appropriate (Services, Operations, etc.). Comments (comment element) should be used to provide only the high-level summary.
Comments	· Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 11, 15, 16, 17, 18.

Element	services
Type	ServicesType
Usage	REQUIRED, MUST be used once and only once
Definition	Container element of all the elements of service coverage. This includes both the necessary staff and facilities. Indicator of the availability of specialty service coverage.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18.

Element	futureServices
Type	FutureServicesType
Usage	OPTIONAL, MAY be used more than once
Definition	Optional list of Service Capabilities in future for planned or ramping up (or down) of capabilities to accomodate surge needs or degraded capabilities. 0...n
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18.

Element	activityInPeriod
Type	ActivityInPeriodType
Usage	OPTIONAL, MAY be used more than once
Definition	Provides a set of summaries of activity that has occured in the indicated reporting period. This item is intended to provide a very high-level of facility activity.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 5, 8, 11, 15, 16, 17, 18.

Element	operations
Type	OperationsType
Usage	OPTIONAL, MAY be used more than once
Definition	Provides a taxonomy-based list of operations that describe the operations of the Facility. Operations are the inward-facing capabilities that a Facility requires to run (e.g. HVAC, power, quarantine, Emergency Operations Centre).
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3.

Element	resourceInformation
Type	ResourceInformationType
Usage	OPTIONAL, MAY be used more than once
Definition	Staffing provides an indication of the staffing status and any needs or offers of this facility.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17, 18.

Element	staffing
Type	ResourceInformationType
Usage	OPTIONAL, MAY be used more than once
Definition	Staffing provides an indication of the staffing status and any needs or offers of this facility.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 17, 18.

Element	emergencyDepartment
Type	EmergencyDepartmentType
Usage	OPTIONAL, MAY be used once and only once
Definition	Report on the emergency department status for the organization.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11.

Element	traumaCenter
Type	TraumaCenterType
Usage	OPTIONAL, MAY be used once and only once
Definition	Type of the trauma center for the organization.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 11, 17.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	Provides context to the FacilityType..
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19.

Attribute	ID
Type	xs:ID
Usage	REQUIRED, MUST be used once and only once
Definition	A unique identifier for this Facility. This value should be unique globally, but MUST be unique from the sender perspective.
Comments	·
Constraints	·
Requirements Supported	Requirement Number 1, 3.

Attribute	parentID
Type	xs:IDREF
Usage	OPTIONAL, MAY be used once and only once.
Definition	Reference to the ID of the Facility that is the parent (owner, manager, responsible, etc.) of this Facility. This field is optional and used to provide hierarchy for formal facility organizations.
Comments	·
Constraints	·
Requirements Supported	Requirement Number 1, 3.

4.1.3 BedCapacityType

Element	BedCapacityType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Top level complex schema type defining bed capacity counts (available/baseline) given a specific type of bed.
Comments	·
Constraints	·
Sub-elements	· availableCount · baselineCount · comment
Requirements Supported	Requirement Number 1, 13, 14.

Element	availableCount
Type	xs:integer
Usage	REQUIRED, MUST be used once and only once
Definition	The number of vacant/available beds to which patients can be immediately supported. 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. NEGATIVE values means the service is operating beyond normal capacity.
Comments	·
Constraints	·
Requirements Supported	Requirement Number 1, 13, 14.

Element	baselineCount
Type	xs:integer
Usage	OPTIONAL, MAY be used once and only once
Definition	The maximum (baseline) number of beds in this category.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 13, 14.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	Provides context for the BedCapacityType.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19.

4.1.4 StabilityType

Element	StabilityType
Type	xs:simpleType (restriction base: xs:string)
Usage	REQUIRED, MUST be used once and only once
Definition	Indication of stability - positive/improving, negative/deteriorating, neutral/stable.
Comments	·
Constraints	MUST use one of the following values: · stable -- Stable/unchanging - conditions remain within norms and are not out of normal patterns · improving -- Conditions are improving towards normal · deteriorating -- Conditions are deviating negatively from normal
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 6, 11, 15, 16, 17, 18.

4.1.5 OffLoadKind Element

Element	OffLoadKind
Type	xs:simpleType (restriction base: xs:token)
Usage	REQUIRED, MUST be used once and only once
Definition	MUST use one of the following values: · land · air · other
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

4.1.6 OffloadStateKind Element

Element	OffloadStateKind
Type	xs:simpleType (restriction base: xs:token)
Usage	REQUIRED, MUST be used once and only once
Definition	MUST use one of the following values: · normal · delayed
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

4.1.7 OffloadType

Element	OffloadType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Indicator of offload times of ambulance capabilities. The time it takes transfer care of a patient to hospital staff, thereby freeing the transport for assignment.
Comments	·
Constraints	·
Sub-elements	· kind · offloadMinutes · offloadState · offloadColourCode · remarks
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	kind
Type	OffloadKind [xs:simpleType (restriction base: xs:token)]
Usage	REQUIRED, MUST be used once and only once
Definition	The mode of transport for offload (land, air, other).
Comments	· Default: land
Constraints	MUST use one of the following values: · land · air · other
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	offloadMinutes
Type	xs:integer
Usage	REQUIRED, MUST be used once and only once
Definition	Average offload time in minutes.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	offloadColourCode
Type	ColourStatusType
Usage	OPTIONAL, MAY be used once and only once
Definition	Colour (text-based) of the Offload capabilities status. By default triage colours of green, yellow, orange, red, black are supported.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	Provides context to the OffloadType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19.

4.1.8 OrganizationInformationType

Element	OrganizationInformationType
Type	xs:complexType [xpil:OrganisationDetailsType]
Usage	REQUIRED, MUST be used more than once
Definition	The container element for organization information elements.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 9, 10.

4.1.9 StatusType

Element	StatusType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Complex Type to provide status information: OK (yes/no), colour code, Stability, and commentary.
Comments	·
Constraints	·
Sub-elements	· isOK · colourStatus · stability · comments
Requirements Supported	Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17.

Element	isOK
Type	xs:boolean
Usage	REQUIRED, MUST be used once and only once
Definition	Is the service/capability available/functioning/adequate? True = yes, false = no.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17.

Element	colourStatus
Type	ColourStatusType
Usage	OPTIONAL, MAY be used once and only once
Definition	Colour (text-based) of the status. By default triage colours of green, yellow, orange, red, black are supported. Element colourStatus can apply to Facility, Services, and Operations.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17.

Element	stability
Type	StabilityType
Usage	OPTIONAL, MAY be used once and only once
Definition	Indication that the Status is stable, improving, or deteriorating
Comments	·
Constraints	MUST use one of the following values: · stable -- Stable/unchanging - conditions remain within norms and are not out of normal patterns · improving -- Conditions are improving towards normal · deteriorating -- Conditions are deviating negatively from normal
Requirements Supported	Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	Provides context to the OffloadType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19.

Element	comments
Type	FreeTextType
Usage	OPTIONAL, MAY be used once and only once
Definition	Provides context to StatusType.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19.

4.1.10 ServiceType

Element	ServiceType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Extensible Service Type for providing detail on a health Service that the Facility provides
Comments	·
Constraints	·
Sub-elements	· name · code · status · externalCode · bedCapacity · capacity · remarks · ref="ext:extension
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	name
Type	FreeTextType [LimitedString (restriction base: xs:string)]
Usage	REQUIRED, MUST be used once and only once
Definition	The human-readable name of the service that is being described.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17.

Element	code
Type	xs:simpleType (restriction base: ServiceCodeDefaultType)
Usage	REQUIRED, must be used once and only once
Definition	See ServiceCodeDefaultType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17.

Element	status
Type	StatusType
Usage	REQUIRED, MUST be used once and only once
Definition	Describes the status of the service.
Comments	· Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type.
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	externalCode
Type	edxl-ct:ValueKeyType
Usage	OPTIONAL, MAY be more than once
Definition	Allows an external system to place its own equivalent code for the service.code value. This allows external systems to correlate their data directly in the HAVE report.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17.

Element	bedCapacity
Type	BedCapacityType
Usage	OPTIONAL, MUST be used once and only once
Definition	An indication of the bed capacity that the facility makes available for the community to know. It reflects fully staffed and equipped beds. intention here is to provide an external view of where beds may be available in health network. The intent is not for HAVE to become a hospital administration tool.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 13, 14.

Element	capacity
Type	CapacityType
Usage	OPTIONAL, MAY be used once and only once
Definition	Indicates the capacity status of this particular service..
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 13, 14.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	Textual description of Service situation.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 13, 14, 17, 19.

Element	ext:extension See Section 3.2.4 EDXL Extensions
Type
Usage	OPTIONAL, MAY be used more than once
Definition	Provides extensibility for adding elements to the ServiceType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 14, 16.

4.1.11 ResourceInformationType

Element	ResourceInformationType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Complex Type to be used for tracking Resource state (status, needs, offers). Allows extension to handle specific information that is non-HAVE (e.g. NIEM payloads, lookups for interoperability with other systems).
Comments	·
Constraints	·
Sub-elements	· status · needs · offers · remarks · ext:extension
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17, 18.

Element	status
Type	StatusType
Usage	REQUIRED, MUST be used once and only once.
Definition	Overall resource status of the facility.
Comments	· Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type.
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	needs
Type	ResourceQuantityType
Usage	OPTIONAL, MUST be used once and only once
Definition	Resource Needs.
Comments	· Uses <resourceNeeds>element
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	resourceNeed
Type	ResourceQuantityType
Usage	OPTIONAL, MAY be used once and only once
Definition	Identifies a need for a particular resource.
Comments	· Used by <needs> element
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	offers
Type	ResourceQuantityType
Usage	OPTIONAL, MAY be used once and only once
Definition	Resource Offers (resources that can be made available to other Facilities).
Comments	· Uses <resourceOffers> element
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	resourceOffer
Type	ResourceQuantityType
Usage	REQUIRED, MAY be used more than once
Definition	Indicates the amount of this particular resource on offer.
Comments	· Used by <offers> element
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MUST be used once and only once
Definition	Provides context for the ResourceInformationType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 5, 6, 11, 13, 14, 17, 19.

Element	ext:extension See Section 3.2.4 EDXL Extensions
Type
Usage	OPTIONAL, MAY be used more than once
Definition	Used to add elements to the ResourceInformationType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 14, 16.

4.1.12 ResourceQuantityType

Element	ResourceQuantityType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Type for stating a quantity of a particular kind of resource.
Comments	· The examples below for resourceKind, quantity, and resourceSize reflect the availability (or request) for 4 Boxes of Small Gloves (200 gloves in each box).
Constraints	·
Sub-elements	· resourceKind · quantity · resourceSize · remarks
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	resourceKind
Type	edxl-ct:ValueKeyType
Usage	REQUIRED, MUST be used once and only once
Definition	The kind (type) of resource that the quantity refers to. (e.g. “Latex Gloves”)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	quantity
Type	xs:double
Usage	OPTIONAL, MUST be used once and only once
Definition	The quantity of the particular Resource. (e.g. “4 boxes”)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	resourceSize
Type	ext:ParameterNameType
Usage	REQUIRED, MAY be used once and only once
Definition	Quantity and Unit of measure (e.g. “Box of 200 Size Small”)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MUST be used once and only once
Definition	Textual description of Resource quantity.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

4.1.13 ColourStatusType

Element	ColourStatusType
Type	xs:complexType
Usage	OPTIONAL, MAY be used once and only once
Definition	Type that allows the structured use of colour-codes to portray state.
Comments	·
Constraints	·
Sub-elements	· colourCode · statusDescription
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	colourCode
Type	ColourCodeDefaultType
Usage	REQUIRED, MUST be used once and only once
Definition	Colour (text-based) of the status. By default triage colours of green, yellow, orange, red, black are supported.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	statusDescription
Type	FreeTextType [LimitedString (restriction base: xs:string)]
Usage	OPTIONAL, MAY be used once and only once
Definition	Human-readable text describing the reason for selection of the particular colour-code.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17.

4.1.14 ServiceCodeDefaultType

Element	ServiceCodeDefaultType
Type	xs:simpleType (restriction base: edxl-ct:ValueType)
Usage	REQUIRED, MUST be used once and only once
Definition	Enumerated list of default service codes
Comments	·
Constraints	·
Sub-elements	· airborneInfectionIsolation · burnUnit (Burn Center services.) · cardiology (Cardiology services.) · cardiology.invasive (Cardiology with invasive capabilities.) · cardiology.noninvasive (Cardiology with NO invasive capabilities.) · cardiologymi.STEMI (STEMI support.) · cardiologymi.nonSTEMI (NO STEMI support.) · cardiology.telemetry (For remote monitoring of cardiology telemetry data for patient.) · dialysis (Dialysis services.) · emergencyDepartment · hyperBaricChamber (Hyperbaric Chamber) · infectiousDisease (Infectious Disease Service.) · intensiveCare.adult (Adult ICU services.) · intensiveCare.neonatal (Neonatal Intensive Care Unit (ICU) services.) · intensiveCare.pediatric (Pediatric Intensive Care Unit (ICU) services.) · intermediateCare (For low-risk, chronically or critically ill patients.) · neonatology (Neonatology) · neurology (Neurology Services.) · neurology.invasive (Neurology-Invasive services, including invasive catheterization.) · neurology.noninvasive (Neurology-Non-Invasive services with no invasive catheterization capability.) · obgyn (OBGYN services.) · obgyn.withLaborDelivery (OBGYN with labor delivery.) · obgyn.withoutLaborDelivery (OBGYN without labor delivery capabilities.) · operatingRooms · ophthalmology (Opthalmology services.) · orthopedic (Orthopedic services.) · pediatrics (Pediatrics services.) · psychiatric (Psychiatric services.) · surgery (Surgery capabilities.) · surgery.adultGeneral (General Adult surgery capabilities.) · surgery.pediatrics (General Pediatric surgery capabilities.) · surgery.orthopedics (Orthopedic surgery capabilities.) · surgery.neurosurgery (Neurosurgery capabilities.) · surgery.facial (Facial surgery capabilities.) · surgery.cardiothoracic (Cardiothoracic surgey capabilities.) · surgery.hand (Hand surgery capabilities.) · surgery.reimplantation (Reimplantation surgery capabilities.) · surgery.spinal (Spinal surgery capabilities.) · surgery.vascular (Vascular surgery capabilities.) · surgery.anesthesia (Anesthesia services.) · traumaCenter (TraumaCenter.)
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 12, 14, 15, 16, 17.

4.1.15 CapacityType

Element	CapacityType
Type	xs:complexType
Usage	REQUIRED, MAY be used once and only once
Definition	Extensible list (name/value pair) for Service capacity. See the HAVE 2.0 standard document for a suggested list of capacities.
Comments	·
Constraints	·
Sub-elements	· capacity · capacityURI
Requirements Supported	Requirement Numbers 1, 13, 14.

Element	capacity
Type	ext:ParameterValueType
Usage	OPTIONAL, MUST be used once and only once
Definition	An indication of the maximum availability of a measureable resource.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 13, 14.

Element	capacityURI
Type	edxl-ct:ValueListURIType
Usage	OPTIONAL, MAY be used once and only once
Definition	A reference to more detailed information about the capacity of the service.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 13, 14.

4.1.16 TriageCountType

Element	TriageCountType
Type	xs:complexType
Usage	OPTIONAL, MAY be used once and only once
Definition	The number of each triage patient type the overall hospital currently has by colour code
Comments	·
Constraints	·
Sub-elements	· code · count · alternateCodeValue · comment
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	code
Type	TriageColourCodeType
Usage	OPTIONAL, MAY be used once and only once
Definition	Triage Colour Codes (RED, YELLOW, GREEN, BLACK, none) for capacity purposes. The list of values must be from the list identified in TriageCodeListURN. Default 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.
Comments	·
Constraints	· If a TriageCountType/code value is specified, a TriageCountType/count element must be specified.
Requirements Supported	Requirement Numbers 1, 6.

Element	count
Type	xs:int
Usage	OPTIONAL, MAY be used once and only once
Definition	The number of patients of this code type.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	alternateCodeValue
Type	edxl-ct:ValueKeyType
Usage	OPTIONAL, MAY be used once more than once
Definition	There are a large number of Triage systems in use. Many use numbering systems (http://en.wikipedia.org/wiki/Triage#Tags) and colours. The premise of HAVE is that we will share the general state with the broad emergency community who may not know the intimate details of a triage system, but understand the general concepts that Red=urgent, Green=walking wounded, Black=Dead/Lost (already dead or untreatable). The alternateCodeValues element is intended to be used by these systems. Providing the ValueListURI and Value will mapping of external systems to the base HAVE Triage colour codes.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 6.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MUST be used once and only once
Definition	Provides context for the TriageCountType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

4.1.17 ActivityInPeriodType

Element	ActivityInPeriodType
Type	xs:complexType
Usage	OPTIONAL, MAY be used once and only once
Definition	ActivityInPeriodType gathers information about the admissions, discharges, and deaths in a time period
Comments	·
Constraints	·
Sub-elements	· reportingPeriod · admissions · discharges · deaths · remarks
Requirements Supported	Requirement Numbers 1, 8.

Element	reportingPeriod
Type	edxl-ct:TimePeriodType
Usage	OPTIONAL, MAY be used once and only once
Definition	The time period (From -- To) that the activity occured in. If this element is not included the reportingPeriod at the Facility level should be assumed to define the time range.
Comments	·
Constraints	Must use · fromDateTime · toDateTime
Requirements Supported	Requirement Numbers 1, 8.

Element	admissions
Type	xs:int
Usage	REQUIRED, MUST be used once and only once
Definition	Number of admissions in the period.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	discharges
Type	xs:int
Usage	REQUIRED, MUST be used once and only once
Definition	Number of Discharges in the period.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	deaths
Type	xs:int
Usage	REQUIRED, MUST be used once and only once
Definition	Number of Deaths in the period.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	General comment/summary of the activity in period.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

4.1.18 TriageColourCodeType

Element	TriageColourCodeType
Type	xs:simpleType
Usage	REQUIRED, MUST be used once and only once
Definition	MUST use one of the following values · red (RED Triage - Immediate attention for Triage.) · yellow (YELLOW Triage - Needs medical attention after RED/Immediate.) · green (GREEN Triage - Walking wounded or self-treatable.) · black (BLACK Triage - Lost/Dead.)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

4.1.19 FreeTextType

Element	FreeTextType
Type	LimitedString
Usage	REQUIRED, MUST be used once and only once
Definition	A restricted text block for preserving whitespace but limiting length to 1024 characters based on the “LimitedString” type. Intended to discourage lengthy descriptions.
Comments	·
Constraints	·
Sub-elements	· defaultText · alternateText
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	defaultText
Type	LimitedString
Usage	REQUIRED, MUST be used once and only once
Definition	Text in the language specified by the HAVE message’s defaultLanguage attribute.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

Element	alternateText
Type	AlternateTextType
Usage	OPTIONAL, MAY be used more than once
Definition	Text in alternate language, for use when the language is other than that specified by the defaultLanguage tag of the root HAVE element.
Comments	· Supports multiple languages in addition to the default language of the HAVE message. · The meaning of the alternateText should be a translation of the defaultText element.
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

4.1.20 AlternateTextType

Element	AlternateTextType
Type	xs:complexType
Usage	See Usage for elements of type AlternateTextType.
Definition	Allows for non default language to be used and is a LimitedString language attribute for this element. Attribute value for language MUST comply with RFC3066.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11.

4.1.21 FacilityOperationKind Element

Element	FacilityOperationKind
Type	xs:simpleType (restriction base: xs:token)
Usage	REQUIRED, MUST be used once and only once
Definition	Must use one of the following: · plant (Plant - the key equipment and capabilities needed to operate the facility (e.g. HVAC, cafeteria).) · security (Security operations for facility (e.g. patrol, surveillance).) · staffing (Staff-related operations (e.g. medical personnel, support staffing, administrative).) · emergency (Emergency Department operations.)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

4.1.22 OperationType

Element	OperationType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Gathers information about a particular operation type including the kind (taxonomy driven), name (human readable representations), status, and commentary.
Comments	·
Constraints	·
Sub-elements	· name · status · remarks · ext:extension
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

Element	kind
Type	FacilityOperationKind
Usage	REQUIRED, MUST be used once and only once
Definition	The high-level kind of operation that is being reported on (plant, security, staffing, or emergency).
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

Element	name
Type	FreeTextType
Usage	REQUIRED, MUST be used once and only once
Definition	The name of the operation that is being reported on (e.g. "Food Services").
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

Element	status
Type	StatusType
Usage	REQURED, MUST be used once and only once
Definition	The status of the Operation.
Comments	· Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type.
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	General comment/summary on the Operation.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	ext:extension See Section 3.2.4 EDXL Extensions
Type
Usage	OPTIONAL, MAY be used more than once
Definition	Used to add elements to the OperationType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 14, 16.

4.1.23 ColourCodeDefaultType

Element	ColourCodeDefaultType
Type	xs:simpleType (restriction base: edxl-ct:EDXLStringType)
Usage	REQUIRED, MUST be used once and only once
Definition	MUST use one of the following · red (RED - severe/extreme deviation from normal condition. Marks a noted exception from normal conditions.) · yellow (YELLOW - moderate deviation from normal condition but not at SEVERE/EXTREME level.) · green (GREEN - normal conditions.)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

4.1.24 FacilityKindType

Element	FacilityKindType
Type	xs:simpleType (restriction base: edxl-ct:EDXLStringType)
Usage	REQUIRED, MUST be used once and only once
Definition	MUST use one of the following · Hospital · longTermCare · urgentCareClinic · temporaryFacility · other
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

4.1.25 TraumaCenterLevelKind

Element	TraumaCenterLevelKind
Type	xs:simpleType (restriction base: xs:token)
Usage	REQUIRED, MUST be used once and only once
Definition	MUST use one of the following · level1 (Level 1 Trauma Services.) · level2 (Level 2 Trauma Services.) · level3 (Level 3 Trauma Services.) · no trauma (Level 4 Trauma Services.)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

4.1.26 LimitedString

Element	LimitedString
Type	xs:simpleType (restriction base: xs:string)
Usage	OPTIONAL, MUST be used once and only once
Definition	Text block for preserving whitespace but limiting length to 1024 characters.
Comments	·
Constraints	· xs:whitespace = “0” · xs:maxLength = “1024”
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11, 15, 16, 17.

4.1.27 GeoLocationType

Element	GeoLocationType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Used to provide accurate geospatial information about location.
Comments	·
Constraints	·
Sub-elements	· wgs84Location · geoLocationExtended
Requirements Supported	Requirement Numbers 1, 3, 5, 10.

Element	wgs84Location
Type	xs:complexType (extension base: edxl-gsf:EDXLGeoLocationType)
Usage	REQUIRED, MUST be used once and only once
Definition	The location of the facility in WGS84 coordinates. The values in this element must use the WGS84 (EPSG:4326) values. This element is mandatory to ensure compatibility globally. If alternate SRS are needed, use the geoLocationExtended elements to support 1 or more SRS that are needed in your community. FUTURE versions of HAVE may support additional or alternate globally supported SRS.
Comments	· srsName attribute is set to a fixed value of http://www.opengis.net/def/crs/EPSG/0/4326 · srsName is the GML Spatial Reference System Name.
Constraints
Requirements Supported	Requirement Numbers 1, 3, 5, 10.

Element	geoLocationExtended
Type	xs:complexType (extension base: edxl-gsf:EDXLGeoLocationType)
Usage	OPTIONAL, MAY be used more than once
Definition	The location of the facility in non-WGS84 (EPSG:4326) coordinates. These alternate (and optional) coordinates are intended for the purposes of systems that require the sending system to provide specialize SRS coordinates.
Comments	·
Constraints	· attribute srsName is required
Requirements Supported	Requirement Numbers 1, 3, 5, 10.

4.1.28 TrafficStatusKind

Element	TrafficStatusKind
Type	xs:simpleType (restriction base: xs:token)
Usage	REQUIRED, MUST be used once and only once
Definition	MUST use one of the following · normal (Traffic is at levels that are within norms.) · advisory (Traffic levels are high enough to warrant notifying the that the facility is experiencing higher than expected traffic. · closed (Facility is not accepting patient traffic.)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18.

4.1.29 OffloadInfoType

Element	OffloadInfoType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Provides information about offload.
Comments	·
Constraints	·
Sub-elements	· offload · ext:extension
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	offload
Type	OffloadType
Usage	REQUIRED, MAY be used more than once
Definition	The particular offload mode, status, and other information for the facility.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	ext:extension See Section 3.2.4 EDXL Extensions
Type
Usage	OPTIONAL, MAY be used more than once
Definition	Used to add elements to the OffloadInfoType
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 14, 16.

4.1.30 EmergencyDepartmentType

Element	EmergencyDepartmentType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	The container of all of the elements related to the emergency department status. It describes the ability of this emergency department to treat patients.
Comments	·
Constraints	·
Sub-elements	· status · offloadInfo · traffic · triageCapacity
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11, 13, 14, 17, 18.

Element	status
Type	StatusType
Usage	REQUIRED, MUST be used once and only once
Definition	Status of the Emergency Department.
Comments	· Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type.
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 11, 15, 16, 17, 18.

Element	offloadInfo
Type	OffloadInfoType
Usage	OPTIONAL, MAY be used once and only once
Definition	Information about the Offload state for various modes of transport (Ambulance, Air Ambulance)
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18

Element	traffic
Type	TrafficType
Usage	OPTIONAL, MAY be used once and only once
Definition	Ability of this emergency department to receive patients via emergency medical services.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18.

Element	triageCapacity
Type	TriageCapacityType
Usage	OPTIONAL, MAY be used once and only once
Definition	The number of each triage patient type the hospital can accept.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

4.1.31 TriageCapacityType

Element	TriageCapacityType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	The Count for a particular triage level.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

4.1.32 TrafficType

Element	TrafficType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Provides context for the TriageCountType
Comments	·
Constraints	·
Sub-elements	· status · colourStatus · reason · remarks
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18.

Element	status
Type	TrafficStatusKind
Usage	REQUIRED, MUST be used once and only once
Definition	The operating status of the Emergency Department (normal, advisory, closed).
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 11, 15, 16, 17, 18.

Element	colourStatus
Type	ColourStatusType
Usage	REQUIRED, MUST be used once and only once
Definition	Colour-code status for the Emergency Department.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	reason
Type	FreeTextType [LimitedString (restriction base: xs:string)]
Usage	OPTIONAL, MAY be used once and only once
Definition	The rationale for the colourStatus. It is used to report the contributing factor to an EMSTraffic Status.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MUST be used once and only once
Definition	General comment/summary on the traffic status.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

4.1.33 TraumaCenterLevelType

Element	TraumaCenterLevelType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Container for Trauma Center Information. Information provided about the Trauma Center (e.g. Trauma Center Level, status, commentary, etc.)
Comments	·
Constraints	·
Sub-elements	· serviceLevel · status · remarks · ext:extension
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	serviceLevel
Type	TraumaCenterLevelKind
Usage	REQUIRED MUST be used once and only once
Definition	Trauma Center Level - 1 through 3 (I trough III) per American of Surgeons. Beyond Level 3 there is no global standard but this is a good approximation.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	status
Type	StatusType
Usage	REQUIRED, MUST be used once and only once
Definition	The status of the Facility Trauma Center.
Comments	· Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type.
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MUST be used once and only once
Definition	General comment/summary on the trauma center status.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

Element	ext:extension See Section 3.2.4 EDXL Extensions
Type
Usage	OPTIONAL, MAY be used more than once
Definition	Used to add elements to the TraumaCenterLevelType.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 14, 16.

4.1.34 ServicesType

Element	ServicesType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Specifies information about a service. Container for a list of Services offered by a Facility.
Comments	·
Constraints	·
Sub-elements	· service · comment
Requirements Supported	Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18.

Element	service
Type	ServiceType
Usage	REQUIRED, MAY be used more than once
Definition	Service provides a description of a particular service - availability, capacity, and status.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	General comment/summary on all of the services.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

4.1.35 FutureServicesType

Element	FutureServicesType
Type	xs:complexType
Usage	REQUIRED, MAY be used more than once
Definition	ServiceListItem provides a description of a particular service - availability, capacity, and status.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18.

Element	service
Type	ServiceType
Usage	OPTIONAL, MUST be used once and only once
Definition	Service provides a description of a particular service - availability, capacity, and status.
Comments	·
Constraints	·
Sub-element	· reportingPeriod
Requirements Supported	Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18.

Element	reportingPeriod
Type	edxl-ct:TimePeriodType
Usage	REQUIRED, MUST be used once and only once
Definition	The Reporting Period (interval between a from time and to time) applying to the future Service.
Comments	·
Constraints	Must use · fromDateTime · toDateTime
Requirements Supported	Requirement Numbers 1, 8.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	General comment/summary on the all of the future services.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

4.1.36 OperationsType

Element	OperationsType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Information about operations in a facility.
Comments	·
Constraints	·
Sub-elements	· operation · comment
Requirements Supported	Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

Element	operation
Type	OperationType
Usage	REQUIRED, MUST used once and only once
Definition	Operation that facility provides in the context of key areas such as Clinical Operations, Security Operations, Facility Operations.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 3.

Element	remarks
Type	edxl-ct:RemarksType
Usage	OPTIONAL, MAY be used once and only once
Definition	General comment/summary on all of the operations.
Comments	·
Constraints	·
Requirements Supported	Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19.

4.1.37 TraumaCenterType

Element	TraumaCenterType
Type	xs:complexType
Usage	REQUIRED, MUST be used once and only once
Definition	Trauma Center Level of this facility. The Choice/Sequence approach here allows for at least one of Adult or Pediatric Trauma Center Levels to be provided.
Comments	·
Constraints	·
Sub-elements	· Adult · pediatric
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	adult
Type	TraumaCenterLevelType
Usage	REQUIRED, MUST be used once and only once
Definition	Adult Trauma Services detail.
Comments	· The Choice/Sequence approach used here allows for at least one of Adult or Pediatric Trauma Center Levels to be provided.
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

Element	pediatric
Type	TraumaCenterLevelType
Usage	OPTIONAL REQUIRED, MUST MAY be used once and only once
Definition	General comment/summary on all of the operations.
Comments	· The Choice/Sequence approach used here allows for at least one of Adult or Pediatric Trauma Center Levels to be provided.
Constraints	·
Requirements Supported	Requirement Numbers 1, 3, 4, 6, 11, 17, 18.

5 Conformance

5.1 Conformance Targets

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

EDXL-HAVE Message; and

EDXL-HAVE Message Producer.

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

NOTE There is no conformance target corresponding to the consumers of EDXL- HAVE messages

5.2 Conformance as an EDXL-HAVE Message

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

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

b) if its namespace name is "urn:oasis:names:tc:emergency:edxl:have:2.0", and the element is valid according to the schema edxl-have-v2.0.xsd in the “Additional artifacts” noted on the front page of this specification

c) if its namespace name is "urn:oasis:names:tc:emergency:edxl:have:2.0", then its content (which includes the content of each of its descendants) meets all the additional mandatory requirements provided in the specific subsection of Section 4 corresponding to the element’s name.

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

5.3 Conformance as an EDXL-HAVE Message Producer

A software entity is a conforming EDXL-HAVE Message Producer if and only if it is constructed in such a way that any XML 1.0 element produced by it and present in a place in which a conforming EDXL- HAVE message is expected (based on contextual information) is indeed a conforming EDXL- HAVE message according to this standard.

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

– a standard distribution protocol (say, EDXL-DE) transfers EDXL- HAVE messages; a resource consumer has sent a request message for an EDXL-HAVE report message to a Hospital system which claims to be a conforming EDXL- HAVE Message Producer, and has received an EDXL-DE message which is therefore expected to carry a conforming EDXL- HAVE Message;

– a local test environment has been set up, and the application under test (which claims to be a conforming EDXL- HAVE Message Producer) has the ability to produce an EDXL- HAVE message 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 Messages.

Appendix A. Acknowledgments

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

Patti Aymond, IEM

Rex Brooks, Individual

Lizzie DeYoung, MITRE

Tom Ferrentino, Individual

Tim Grapes, Individual

Elysa Jones, Individual

Emily Laughren, MITRE

Donald McGarry, MITRE

Mark Prutsalis, Sahana Software Foundation

Rob Torchon, Individual

Brian Wilkins, MITRE

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

Doug Allport, Canadian Public Safety Operations Organization

David Askov, Pacific Disaster Center

Patti Aymond, IEM

Art Botterell, Individual

Rex Brooks, Individual

Robert Bunge, NOAA's National Weather Service

Yu Chen, Google Inc.

Eliot Christian, Individual

Toby Considine, University of North Carolina at Chapel Hill

William Cox, Individual

CAPAU Custodian, Australian Government Attorney-General's Department

Lizzie DeYoung, MITRE Corporation

Thomas Ferrentino, Individual

Mike Gerber, NOAA's National Weather Service

Timothy Grapes, Individual

Robert Gustafson, MITRE Corporation

Steve Hakusa, Google Inc.

Gary Ham, Individual

Werner Joerg, Individual

Elysa Jones, Individual

Michael Kristan, MITRE Corporation

Ram Kumar, Individual

Dominic König, Sahana Software Foundation

Emily Laughren, MITRE Corporation

Mark Lucero, US Department of Homeland Security

Donald McGarry, MITRE Corporation

Thomas Merkle, US Department of Homeland Security

Darrell O'Donnell, Individual

Camille Osterloh, Individual

Norm Paulsen, Environment Canada

Glenn Pearson, Sahana Software Foundation

Efraim Petel, AtHoc, Inc.

Tomer Petel, AtHoc, Inc.

Mark Prutsalis, Sahana Software Foundation

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

Aviv Siegel, AtHoc, Inc.

Steve Streetman, US Department of Homeland Security

Robert Torchon, Individual

Richard Vandame, US Department of Homeland Security

Nuwan Waidyanatha, Sahana Software Foundation

Jeff Waters, US Department of Defense (DoD)

Jacob Westfall, Individual

Herbert White, NOAA's National Weather Service

Brian Wilkins, MITRE Corporation

Ka-Ping Yee, Google Inc.

Appendix B. Revision History

Revision	Date	Editor	Changes Made
WD02	23DEC2014	Darrell O’Donnell	Preparation for submission to OASIS EM-TC
WD02	13JAN2015	Darrell O’Donnell	Updates to reflect RIM (CT, CIQ, and GSF) working drafts.
CSD01	13JAN2015	Darrell O’Donnell	Updates to reflect EM TC Committee Specification Draft
WD03	22AUG2017	Rex Brooks	Changes pursuant to new Committee Specification Public Review Draft