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

Committee Specification Draft 03 /
Public Review Draft 03

Proposed HL7® Informative Document

14 August 2018

Specification URIs

This version:

http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd03/edxl-have-v2.0-csprd03.doc (Authoritative)

http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd03/edxl-have-v2.0-csprd03.html

http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd03/edxl-have-v2.0-csprd03.pdf

Previous version:

http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd02/edxl-have-v2.0-csprd02.doc (Authoritative)

http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd02/edxl-have-v2.0-csprd02.html

http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd02/edxl-have-v2.0-csprd02.pdf

Latest version:

http://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.doc (Authoritative)

http://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.html

http://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.pdf

Technical Committee:

OASIS Emergency Management TC

HL7 Patient Administration Work Group

Chair:

Elysa Jones (elysajones@yahoo.com), Individual

Editors:

Darrell O’Donnell (darrell.odonnell@continuumloop.com), Individual

Brian Wilkins (bwilkins@mitre.org), MITRE Corporation

Rex Brooks (rexb@starbourne.com), individual

Scott M. Robertson (scott.m.robertson@kp.org), Kaiser Permanente

Additional artifacts:

This prose specification is one component of a Work Product that also includes:

·         XML schemas: http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd03/schema/

Related work:

This specification replaces or supersedes:

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

This specification is related to:

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

·         Emergency Data Exchange Language Resource Messaging (EDXL-RM) 1.0. Edited by Dr. Patti Aymond, Rex Brooks, Tim Grapes, Gary Ham, Dr. Renato Iannella, Dr. Karen Robinson, Werner Joerg, and Alessandro Triglia. 22 December 2009. OASIS Standard incorporating Approved Errata. http://docs.oasis-open.org/emergency/edxl-rm/v1.0/errata/EDXL-RM-v1.0-OS-errata-os.html.

·         Emergency Data Exchange Language Common Types v1.0. Edited by Werner Joerg, Rex Brooks, Jeff Waters, and Don McGarry. Latest version: http://docs.oasis-open.org/emergency/edxl-ct/v1.0/edxl-ct-v1.0.html.

·         Emergency Data Exchange Language Customer Information Quality v1.0. Edited by Werner Joerg and Jeff Waters. Latest version: http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/edxl-ciq-v1.0.html.

·         HL7 Messaging Standard Version 2.8 – An Application Protocol for Electronic Data Exchange in Healthcare Environments. February 2014. HL7 Normative Standard. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=356

Declared XML namespace:

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

Abstract:

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

Status:

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

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

This specification 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).

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

This document was approved as an HL7 Informative Document by ballot in January 2018. HL7 members should send comments on this specification to the TC’s public comment list, as described above.

Citation format:

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

[EDXL-HAVE-v2.0]

Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 2.0. Edited by Darrell O’Donnell, Brian Wilkins, Rex Brooks, and Scott M. Robertson. 14 August 2018. OASIS Committee Specification Draft 03 / Public Review Draft 03. Proposed HL7 Informative Document. http://docs.oasis-open.org/emergency/edxl-have/v2.0/csprd03/edxl-have-v2.0-csprd03.html. Latest version: http://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.html.

Notices

Copyright © OASIS Open 2018. All Rights Reserved.

Copyright © 2018 Health Level Seven International ® 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 name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

HL7 Notices

Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology

Owner/Contact

Current Procedures Terminology (CPT) code set

American Medical Association
https://www.ama-assn.org/practice-management/cpt-licensing

SNOMED CT

SNOMED International   http://www.snomed.org/snomed-ct/get-snomed-ct or info@ihtsdo.org

Logical Observation Identifiers Names & Codes (LOINC)

Regenstrief Institute

International Classification of Diseases (ICD) codes

World Health Organization (WHO)

NUCC Health Care Provider Taxonomy code set

American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

 

HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off. Please see http://www.hl7.org/legal/trademarks.cfm for additional guidance on Health Level Seven-owned trademarks.

Table of Contents

1        Introduction. 9

1.0 IPR Policy. 9

1.1 Terminology. 9

1.2 Normative References. 9

1.3 Non-Normative References. 10

1.4 Purpose. 11

1.5 History. 11

1.6 Structure of the EDXL Hospital Availability Exchange Specification. 13

2        Design Principles & Concepts (non-normative) 14

2.1 Requirements for Design. 14

2.2 Example Usage Scenarios. 15

2.2.1 Day-to-Day – Dialysis Patient: 15

2.2.2 First Responder – Responding with Critical Care. 15

2.2.3 Mass-Scale Vaccination Clinics. 15

2.2.4 Disaster Response: 15

3        EDXL HAVE. 16

3.1 HAVE Report Definition (non-normative) 16

3.2 Supporting Elements (non-normative) 16

3.2.1 Common Types. 16

3.2.2 Selecting Values from Lists. 17

3.2.3 ValueKeyType. 17

3.2.4 EDXL Extensions. 18

3.3 Element Reference Model (non-normative) 20

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

3.5 HAVE Elements. 21

4        Data Dictionary. 22

4.1.1 HAVE. 22

4.1.2 FacilityType. 24

4.1.3 BedCapacityType. 32

4.1.4 StabilityType. 33

4.1.5 OffLoadKind Element 34

4.1.6 OffloadStateKind Element 34

4.1.7 OffloadType. 35

4.1.8 OrganizationInformationType. 37

4.1.9 StatusType. 37

4.1.10 ServiceType. 40

4.1.11 ResourceInformationType. 43

4.1.12 ResourceQuantityType. 46

4.1.13 ColourStatusType. 48

4.1.14 ServiceCodeDefaultType. 50

4.1.15 CapacityType. 51

4.1.16 TriageCountType. 52

4.1.17 ActivityInPeriodType. 54

4.1.18 TriageColourCodeType. 57

4.1.19 FreeTextType. 57

4.1.20 AlternateTextType. 59

4.1.21 FacilityOperationKind Element 59

4.1.22 OperationType. 59

4.1.23 ColourCodeDefaultType. 62

4.1.24 FacilityKindType. 62

4.1.25 TraumaCenterLevelKind. 63

4.1.26 LimitedString. 63

4.1.27 GeoLocationType. 64

4.1.28 TrafficStatusKind. 65

4.1.29 OffloadInfoType. 65

4.1.30 EmergencyDepartmentType. 67

4.1.31 TriageCapacityType. 69

4.1.32 TrafficType. 69

4.1.33 TraumaCenterLevelType. 71

4.1.34 ServicesType. 73

4.1.35 FutureServicesType. 74

4.1.36 OperationsType. 76

4.1.37 TraumaCenterType. 77

5        Conformance. 79

5.1 Conformance Targets. 79

5.2 Conformance as an EDXL-HAVE Message. 79

5.3 Conformance as an EDXL-HAVE Message Producer 79

Appendix A. Acknowledgments. 80

Appendix B. HL7 Implementation Guidance. 82

B.1 Scope. 82

B.2 HL7 v2.8. 82

B.2.1 HL7 Query Conformance Statement 83

B.2.1.1 Query Profile. 83

B.2.1.2 Query Grammar:  QSB Message (QSB^Z08^QSB_Q16) 84

B.2.1.3 Response Grammar:  RTB Message (RTB^Z09^RTB_Z09) 84

B.2.1.4 QPD Input Parameter Specification. 92

B.2.1.5 Input/Output Specification: Virtual Table. 93

B.2.1.5.1 Virtual Table Field definition – HAVE record. 93

B.2.1.5.2 Virtual Table Field definition – OrganisationInformation. 94

B.2.1.5.3 Virtual Table Field definition – Facility. 97

B.2.1.5.4 Virtual Table Field definition – Operation. 98

B.2.1.5.5 Virtual Table Field definition – Comment 99

B.2.1.5.6 Virtual Table Field definition – Extension. 100

B.2.1.5.7 Virtual Table Field definition – Parameter 100

B.2.1.5.8 Virtual Table Field definition – Value. 100

B.2.1.5.9 Virtual Table Field definition – Service. 101

B.2.1.5.10 Virtual Table Field definition – FutureService. 102

B.2.1.5.11 Virtual Table Field definition – Activity. 103

B.2.1.5.12 Virtual Table Field definition – Resource-Staff 104

B.2.1.5.13 Virtual Table Field definition – Needs-Offers. 105

B.2.1.5.14 Virtual Table Field definition – Emergency Department 105

B.2.1.5.15 Virtual Table Field definition – Offload. 106

B.2.1.5.16 Virtual Table Field definition – Triage. 107

B.2.1.5.17 Virtual Table Field definition – Trauma Center 107

B.2.1.5.18 Virtual Table Field definition – GeoLocation. 108

B.2.1.5.19 Constructing HAVE responses from Virtual Table definitions. 109

B.2.1.6 RCP Response Control Parameter Field Description and Commentary. 109

B.2.2 QSX /ACK - cancel subscription/acknowledge message (Event J02) 110

B.2.2.1 QSX^J02^QCN_J01: Cancel Subscription. 110

B.2.2.2 ACK^J02^ACK: General Acknowledgment 110

B.2.3 Examples. 110

B.2.3.1 Establishing a subscription. 110

B.2.3.2 HAVE report in response to a subscription. 111

B.2.3.3 Cancel a subscription. 111

Appendix C. Revision History. 112

 

 


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 specification 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 as noted in "Additional artifacts" on the 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 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.

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:

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:

 

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:

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:

which stands for

 

<resourceKind>

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

  1. Standard augmentation: community adds new information that is associated with the EDXL standard. Examples: adding HL7 translation information to the HAVE payload.
  2. 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:

 

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:

which stands for

 

<extension>

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

<id>extension:1</id>

<parameter>

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

            <value>Rapidly</value>

</parameter>

</extension>


3.3 Element Reference Model (non-normative)

 


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 (reportingPeriodoptional) that identifies reporting period applicable for this HAVE report, and a group of elements (facilityrequired) 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:

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 Normative XML Schema for EDXL-HAVE-v2.0 available separately as noted in "Additional artifacts" on the front page.

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. HL7 Implementation Guidance

This informative (non-normative) appendix provides guidance to implementers working to integrate HAVE message into Electronic Health Records (EHRs) or other clinical systems where messaging is primarily based upon Health Level Seven International (HL7) standards. 

B.1 Scope

This appendix explores HL7 v2.8 and HL7 Fast Healthcare Interoperability Resources (FHIR®) Release 3.  HL7 v2.x (a generic reference to the “v2 family”, from v2.3.1 to v2.9 (in development)) continues to be widely implemented in clinical systems despite structural inconsistencies and the lack of a defined data model.  This appendix focuses on HL7 v2.8 (with some discussion on v2.x) as a standard for implementing HAVE-like messages.  This version will support the systems/interfaces identified in the scope of this document.

HL7 v3 Messaging, Clinical Document Architecture (CDA®), Consolidated CDA (CCD, CCDA, C-CDA) and their derivatives are out of scope for this appendix.  HL7 v3 Messaging, while based upon a strong data model (HL7 Reference Information Model (RIM)), has not been as widely accepted in clinical systems in many countries, notably including the United States..  The abstract nature of the RIM results in layers of “constraint” to get to specific data elements.  This results in HL7 v3 message instances being very large.  CDA, also based on the RIM, defines a formal structure for clinical documents and structured information.  Many clinical documents (e.g., Discharge Summaries, Consult Notes) have been defined using CCDA and are the basis for Health Information Exchange in the US, and between EHRs and other clinical systems, generally.  While CDA/CCDA is widely used, the “document” concept requires elements which do not relate to the HAVE specification (e.g., a document subject (the patient) and author are both required).

HL7 FHIR®, while still a “Standard for Trial Use” (STU), is based on RESTful API exchange of lightweight, reusable resources which has generated extensive interest and implementation internationally.  While there is an underlying link to HL7 v3 RIM, FHIR® employs business-oriented names for resources and elements.  It should be possible to create FHIR® resources which mirror HAVE structures.  However, due to time and work-resource constraints, developing FHIR materials for HAVE messages in not feasible.  Creating FHIR resources will be held until the next iteration/update to HAVE. 

B.2 HL7 v2.8

The principle difficulty marrying HAVE with HL7 v2.8 (or v2.x) is that there few v2.8 concepts representing the status and availability of services, operations, resources, and emergency room status. The concepts which do exist in v2.8 relate to the perspective of elements needed for a patient encounter – an outpatient appointment, an admission, scheduling a procedure, etc. In addition, these items are addressed on an item-by-item basis (one ICU bed, a 20-minute slot on a CT, etc.) rather than in aggregate (13 ICU beds available, 4 CTs with 50+% availability, etc.).  Developing the aggregate availability with existing messages would entail multiple request-and-response message exchanges.

The v2.8 Query/Response mechanism (see v2.8 Chapter 5 Query) can be employed to “ask questions” not directly supported by existing v2.8 messages.  For this specification, a query can be defined with a “HAVE 2.0 Status” request and a response of HAVE 2.0 information.  (This Query/Response structure has existed since HL7 v2.4, allowing application to systems that have not yet updated to v2.8).  In addition, the Query Profile includes a Publish/Subscribe mechanism which would permit an Emergency Management service/entity to subscribe to a facility’s status and receive ongoing updates to that status.

B.2.1 HL7 Query Conformance Statement

The following is the HL7 Query Conformance Statement adapted (when possible) into the styles and table formats used in this specification.

This section assumes the reader has some familiarity with HL7 v2.8 (or v2.x).  This section follows the definition pattern for an HL7 Query Conformance Statement, but does not go into detail on the message segments and fields.  The reader may need to refer to HL7 v2.8 chapters, reference points are provided below.  Note: The Query construct has been relatively stable from v2.4 through v2.8, thus a person familiar with v2.4 will find that knowledge applicable below.

B.2.1.1 Query Profile

Publication ID (Query ID):

Z08

Type:

Publish

Publication Name:

HAVE 2.0 Subscription

Query Trigger (= MSH-9):

QSB^Z08^QSB_Q16

Query Mode:

Real-time

Response Trigger (= MSH-9):

RTB^Z09^RTB_Z09

Query Characteristics:

Establishes Subscription/Response for HAVE 2.0 report

Purpose:

Established Subscription by Emergency Management entity to healthcare system.  Subsequent responses provide status information, per HAVE 2.0 specification for the Healthcare Facilities employing the healthcare system

Response Characteristics:

When a subscription is established, the publishing system will respond with the facility status at that time.  Subsequent facility status responses will be sent as determined by the Healthcare Facility, e.g., on a defined schedule, upon a significant status change, or as otherwise determined by the requester/facility relationship.

Based on Segment Pattern:

Not applicable for subscription query

Detailed explanation of the Query Profile table can be found in HL7 v2.8 Chapter 5 Section 5.3 “Query/Response Profile.”  For purposes of this specification, a limited discussion follows.

·         Publication ID is an arbitrary identifier for this query profile and related messages.  HL7 conventions dictate that locally defined identifiers begin with “Z” with two following digits.

·         Type identifies this profile as a subscription/response as opposed to a simple query/response

·         Query Trigger and Response Trigger are message/event/structure terms which will be present in the subscription (query) message and response messages. 

B.2.1.2 Query Grammar:  QSB Message (QSB^Z08^QSB_Q16)

Segments

Description

Status

Sec. Ref

MSH

Message Header Segment

 

2.15.9

[{SFT}]

Software Segment

 

2.15.12

[ UAC ]

User Authentication Credential

 

2.14.13

QPD

Query Parameter Definition

 

5.5.4

RCP

Response Control Parameter

 

5.5.6

[ DSC ]

Continuation Pointer

 

2.15.4

Detailed explanation of the Abstract Message Table can be found in HL7 v2.8 Chapter 2 Section 2.12 “Chapter Formats for Defining HL7 Messages.”  For purposes of this specification, a limited discussion follows.

·         Columns

·         Segments identify the order, optionality, and repetition of information segments within the message. 

·         Square brackets, [ ], indicate the segment is optional. 

·         Curly brackets, { }, indicate a segment can repeat.  There is no indication in this table on how many times a segment can repeat

·         Indentation is used to note groups of segments.  Such as when a group of segments are optional as a block, or can repeat as a block.

·         Status is not relevant to this specification

·         Sec. Ref points to the HL7 v2.8 chapter and section where the segment is defined.

·         Rows

·         SFT – Software Segment, UAC – User Authentication Credential, and DSC – Continuation Pointer are optional and not relevant to this specification.  They can be used in implementations, but they are not included in this guidance.  They are not included in the examples below.

 

B.2.1.3 Response Grammar:  RTB Message (RTB^Z09^RTB_Z09)

 

Segments

Description

 

Sec. Ref

MSH

Message Header Segment

 

HL7 2.15.9

[{SFT}]

Software Segment

 

HL7 2.15.12

[UAC]

User Authentication Credential

 

HL7 2.14.13

MSA

Message Acknowledgement

 

HL7 2.15.8

[ERR]

Error

 

HL7 2.15.5

QAK

Query Acknowledgement

 

HL7 5.4.2

QPD

Query Parameter Definition

 

HL7 5.5.4 Error! Reference source not found.

 

---HAVE begin

 

HAVE B.2.1.5.1

RDF

HAVE Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---HAVE-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---HAVE-COMMENT end

 

 

 

---ORGANIZATION begin

 

 

RDF

ORGANIZATION Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

 

---Organization end

 

 

{

---FACILITY begin

 

 

RDF

FACILITY Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FAC-COMMENT end

 

 

 

---FACILITY-ORGANIZATION-INFO begin

 

 

RDF

ORGANIZATION INFO Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

 

---FACILITY-ORGANIZATION-INFO end

 

 

 

---FACILITY-GEOLOCATION begin

 

 

RDF

GEOLOCATION Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

 

---FACILITY-GEOLOCATION end

 

 

{

---FACILITY-SERVICES begin

 

 

RDF

SERVICE Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-SERVICES-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-SERVICES-COMMENT end

 

 

[

---FACILITY-SERVICES-EXTENSION begin

 

 

RDF

EXTENSION Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-SERVICES-EXTENSION end

 

 

}

---FACILITY-SERVICES end

 

 

[{

---FACILITY-FUTURE-SERVICES begin

 

 

RDF

FUTURE SERVICES Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-FUTURE-SERVICES-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-FUTURE-SERVICES-COMMENT end

 

 

[

---FACILITY-FUTURE-SERVICES-EXTENSION begin

 

 

RDF

EXTENSION Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-FUTURE-SERVICES-EXTENSION end

 

 

}]

---FACILITY-FUTURE-SERVICES end

 

 

[{

---FACILITY-ACTIVITY-IN-PERIOD begin

 

 

RDF

ACTIVITY Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-ACTIVITY-IN-PERIOD-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-ACTIVITY-IN-PERIOD-COMMENT end

 

 

}]

---FACILITY-ACTIVITY-IN-PERIOD end

 

 

[{

---FACILITY-OPERATIONS begin

 

 

RDF

OPERATIONS Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-OPERATIONS-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-OPERATIONS-COMMENT end

 

 

[

---FACILITY-OPERATIONS-EXTENSION begin

 

 

RDF

EXTENSION Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-OPERATIONS-EXTENSION end

 

 

}]

---FACILITY-OPERATIONS end

 

 

[{

---FACILITY-RESOURCE-INFO begin

 

 

RDF

RESOURCE Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-RESOURCE-NEEDS begin

 

 

RDF

NEEDS Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-RESOURCE-NEEDS end

 

 

[

---FACILITY-RESOURCE-OFFERS begin

 

 

RDF

OFFERS Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-RESOURCE-OFFERS end

 

 

[

---FACILITY-RESOURCE-INFO-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-RESOURCE-INFO-COMMENT end

 

 

[

---FACILITY-RESOURCE-INFO-EXTENSION begin

 

 

RDF

EXTENSION Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-RESOURCE-INFO-EXTENSION end

 

 

}]

---FACILITY-RESOURCE-INFO end

 

 

[{

---FACILITY-STAFFING begin

 

 

RDF

STAFFING Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-STAFFING-NEEDS begin

 

 

RDF

NEEDS Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-STAFFING-NEEDS end

 

 

[

---FACILITY-STAFFING-OFFERS begin

 

 

RDF

OFFERS Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-STAFFING-OFFERS end

 

 

[

---FACILITY-STAFFING-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-STAFFING-COMMENT end

 

 

[

---FACILITY-STAFFING-EXTENSION begin

 

 

RDF

EXTENSION Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-STAFFING-EXTENSION end

 

 

}]

---FACILITY-STAFFING end

 

 

[{

---FACILITY-EMERGENCY begin

 

 

RDF

EMERGENCY Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-EMERGENCY-OFFLOAD begin

 

 

RDF

OFFLOAD Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-EMERGENCY-OFFLOAD end

 

 

[

---FACILITY-EMERGENCY-TRIAGE begin

 

 

RDF

TRIAGE Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-EMERGENCY-TRIAGE end

 

 

}]

---FACILITY-EMERGENCY end

 

 

[{

---FACILITY-TRAUMA begin

 

 

RDF

TRAUMA Table Row Definition Segment

 

 

RDT

Table Row Data Segment

 

 

[

---FACILITY-TRAUMA-COMMENT begin

 

 

RDF

COMMENT Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-TRAUMA-COMMENT end

 

 

[

---FACILITY-TRAUMA-EXTENSION begin

 

 

RDF

EXTENSION Table Row Definition Segment

 

 

{RDT}

Table Row Data Segment

 

 

]

---FACILITY-TRAUMA-EXTENSION end

 

 

}]

---FACILITY-TRAUMA end

 

 

{

---FACILITY end

 

 

 

---HAVE end

 

 

This message structure is based upon RTB^K19^RTB_K19.  In RTB^Z09^RTB_Z09 the RDF/RDT structure is expanded to address the elements of the HAVE message, e.g., the HAVE record, the Organization Information, the Facility, etc.

The Abstract Message Table is useful for collapsing repetitive message structures.  An expanded message structure, as above, can hide the relationships between the response rows.  The following table summarizes table above in terms of the HAVE elements.

Due to data type and structural differences between the HL7 v2.x and the EDXL formats, some elements had to be extracted from HAVE elements into separate HL7 response records.  For example, the “OFFLOAD” AND “TRIAGE” repeating structures within the “EMERGENCY DEPARTMENT” structure could not be repeated in the available HL7 v2.x structure.  “OFFLOAD” and “TRIAGE” were defined as separate response records in order to permit their repetition.

 

HAVE

            [{HAVE COMMENT}]

            ORGANIZATION

            {FACILITY

                        [{FACILITY COMMENT}]

                        FACITILY ORGANIZATION INFO

                        FACILITY GEOLOCATION

                        {FACILITY SERVICES

                                    [{FACILITY SERVICE COMMENT}]

                                    [{FACILITY SERVICE EXTENSION}]

                        }

                        [{FACILITY FUTURE SERVICES

                                    [{FACILITY FUTURE SERVICE COMMENT}]

                                    [{FACILITY FUTURE SERVICE EXTENSION}]

                        }]

                        [{FACILITY ACTIVITY IN PERIOD

                                    [{FACILITY ACITIVITY IN PERIOD COMMENT}]

                        }]

                        [{FACILITY OPERATIONS

                                    [{FACILITY OPERATION COMMENT}]

                                    [{FACILITY OPERATION EXTENSION}]

                        }]

                        [{FACILITY RESOURCE INFORMATION

                                    [{FACILITY RESOURCE NEEDS}]

                                    [{FACILITY RESOURCE OFFERS}]

                                    [{FACILITY RESOURCE COMMENT}]

                                    [{FACILITY RESOURCE EXTENSION}]

                        }]

                        [{FACILITY STAFFING

                                    [{FACILITY STAFFING NEEDS}]

                                    [{FACILITY STAFFING OFFERS}]

                                    [{FACILITY STAFFING COMMENT}]

                                    [{FACILITY STAFFING EXTENSION}]

                        }]

                        [{FACILITY EMERGENCY DEPARTMENT

                                    [{FACILITY EMERGENCY OFFLOAD}]

                                    [{FACILITY EMERGENCY TRIAGE}]

                        }]

                        [{FACILITY TRAUMA CENTER

                                    [{FACILITY TRAUMA COMMENT}]

                                    [{FACILITY TRAUMA EXTENSION}]

                        }]

            }

     

B.2.1.4 QPD Input Parameter Specification

Field Seq (Query ID=Z08)

ColName

Key/
Search

Sort

LEN

DT

Opt

RP/#

Match Op

TBL #

Segment Field Name

Service Identifier Code

Element Name

1

MessageQueryName

 

 

60

CWE

R

 

 

 

 

 

Message Query Name

2

QueryTag

 

 

32

ST

R

 

 

 

 

 

Query Tag

Detailed explanation of the QPD Input Parameter Specification can be found in HL7 v2.8 Chapter 5 Section 5.3.2.6 “QPD input parameter specification.”  For purposes of this specification, a limited discussion follows:

The QPD input parameter specification defines the content of the QPD – Query Parameter Definition segment in the QSB – Query Subscription message.  This allows for the requestor to provide filtering and sorting criteria to the response table.  In the context of HAVE 2.0, there is no filtering or sorting specified by the requestor.  As such, this table contains only the required MessageQueryName and QueryTag.

 

QPD Input Parameter Field Description and Commentary

Input Parameter (Query ID=Z08)

Comp. Name

DT

Description

MessageQueryName

 

CWE

SHALL be valued Z08^HAVE 2.0 Subscription^HL70471

QueryTag

 

ST

Identifies the subscription and ties responses to the subscription.  Set by requestor.  Included in all responses to this subscription.

The QPD Input Parameter Field Description and Commentary table extends the QPD Input Parameter Specification table, in particular adding a Description.  Further information on structure of this table is available in HL7 v2.8 Chapter 5 Section 2.1.5. 

·         MessageQueryName is assigned a fixed value of “Z08^HAVE 2.0 Subscription^HL70471”

·         HL70471 refers to an HL7 table which is “User Defined”.  That is, the local implementer can “fill” the table with local values.  In this case, the one code table value is “Z08” with a description of “HAVE2.0 Subscription”.

·         QueryTag is a string identifier supplied by the requester and included by the responder with all responses.  This allows the requestor to “tie” the responses back to the subscription.  This may be useful when a requester has subscriptions to multiple facilities.  In examples below, the convention of “<facility name> HAVE 2.0 response to <requester name>” will be used.

 

B.2.1.5 Input/Output Specification: Virtual Table

The section defines the HL7 table response incorporating the HAVE 2.0.  This structure has been modified from the HL7 form as some columns are not used (Key/Search, Sort, Match OP, and Service Identifier Code) and others have been added to clarify HL7/HAVE alignment. 

HL7 Segment-Field, Element Name, and Component Name are used to inform HL7 implementers of matching concepts and constructs between HL7 v2.8 and EDXL HAVE 2.0.  If no HL7 Segment-Field or Element Name is entered, then there is no direct match of the EDXL HAVE 2.0 concept in HL7 2.8 (there isn’t an existing HL7 interface concept that can be reused.

The Virtual Table has also been modified to describe different rows, effectively creating a set of tables

B.2.1.5.1 Virtual Table Field definition – HAVE record

HL7 Column Name (Query ID=Z08) (Uses HAVE element name)

HL7 terms

Length

Data Type

Opt

Rep

Table

HL7 Segment Field

HL7 Element Name

tableLabel

 

ST

R

N

 

 

 

defaultLanguage

 

ID

R

N

ISO369

PID-15.1

Primary Language - identifier

Organization Information

 

 

 

 

 

 

Use Organization record

reportingPeriod

 

DR

O

N

 

 

 

                fromDateTime

 

DTM

R

N

 

 

 

                toDateTime

 

DTM

R

N

 

 

 

Facility

 

 

 

 

 

 

Use Facility record

Comment

 

 

 

 

 

 

Use Comment record

Extension

 

 

 

 

 

 

Use Extension record

Virtual Table Field Description and Commentary – HAVE record

HL7 Column Name (Query ID=Z08) (Uses HAVE element name)

HL7 Component Name

HL7 Data Type

Description

tableLabel

 

ST

Fixed value: “HAVE

Identifies HAVE element represented by this table

defaultLanguage

 

ID

Default language for the HAVE report.  Note that ISO-0369 is used here since it is a known “code table” in HL7.  HAVE refers to RFC 3066 which incorporates ISO-0369.

Organization Information

 

 

Use Organization record

reportingPeriod

Date Range

DR

If not populated, defaults to a current day report.

 

DR is an HL7 composite data type which is similar to edxl-ct:TimePeriodType

                fromDateTime

DR.1 - Range Start Date/Time

DTM

HL7 date-time format:  YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ].

EDXL date-time format: YYYY-MM-DDTHH:MM:SS[-,+]ZZ:ZZ

                toDateTime

DR.2 - Range End Date/Time

DTM

HL7 date-time format:  YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ].

EDXL date-time format: YYYY-MM-DDTHH:MM:SS[-,+]ZZ:ZZ

Facility

 

 

Use Facility record

Comment

 

 

Use Comment record

Extension

 

 

Use Extension record

 

B.2.1.5.2 Virtual Table Field definition – OrganisationInformation

HL7 Column Name (Query ID=Z08) (Uses HAVE element name)

HL7 terms

Length

Data Type

Opt

Rep

Table

HL7 Segment Field

HL7 Element Name

tableLabel

 

ST

R

N

 

 

 

OrganisationName

 

XON

R

Y

 

PRT.8

Participation Organization

                OrganisationID

XON.10 Organization ID

ST

O

N

 

 

 

                OrganisationIDType

XON.7 Identifier Type

ID

O

N

HL70203

 

 

                NameElement

XON.1 Organization Name

ST

O

N

 

 

 

Addresses

 

XAD

O

Y

 

PRT.14

Participation Address

Address-FreeTextAddress -AddressLine[1]

XAD.1.1 Street Address

ST

O

N

 

 

 

Address-FreeTextAddress -AddressLine[2]

XAD.2 Other Designation

ST

O

N

 

 

 

Address-Country-NameElement

XAD.6 Country

ST

O

N

 

 

 

Address-AdministrativeArea-NameElement

XAD.4 State or Province

ST

O

N

 

 

 

Address-AdministrativeArea-SubAdministrativeArea-NameElement

XAD.9.2 County/Parish.Text

ST

O

N

 

 

 

Address-Locality-NameElement

XAD.3 City

ST

O

N

 

 

 

Address-PostCode-Identifier

XAD.5 Zip or Postal Code

ST

O

N

 

 

 

Address-Locality-SubLocality-NameElement

 

ST

O

N

 

 

 

ContactNumbers

XTN extended telecommunication number

XTN

O

Y

 

PRT.15

Participation Telecommunication Address

ContactNumber-CommunicationMediaType

XTN.3 Telecommunication Equipment Type

ST

O

N

 

 

 

ContactNumber-Usage

XTN.2 Telecommunication Use Code

ST

O

N

 

 

 

ContactNumber-ContactNumberElement

XTN.12 Unformatted Telephone Number

ST

O

N

 

 

 

ContactNumber-ContactHours

 

ST

O

N

 

 

 

ElectronicAddressIdentifiers

XTN extended telecommunication number

XTN

O

Y

 

PRT.15

Participation Telecommunication Address

ElectronicAddressIdentifier

XTN.4 Communication Address

ST

R

N

 

 

 

EletronicAddressIdentifer-Type

XTN.3 Telecommunication Equipment Type

ST

O

N

 

 

 

EletronicAddressIdentifer-Usage

XTN.2 Telecommunication Use Code

ST

O

N

 

 

 

OrganizationInfo-Type

 

ST

O

N

 

 

 

OrganizationInfo-CategoryType

 

ST

O

N

 

 

 

OrganizationInfo-Status

 

ST

O

N

 

 

 

OrganizationInfo-Nature

 

ST

O

N

 

 

 

OrganizationInfo-IndustryType

 

ST

O

N

 

 

 

OrganizationInfo-IndustryCode

 

ST

O

N

 

 

 

OrganizationInfo-IndustryCodeType

 

ST

O

N

 

 

 

OrganizationInfo-NumberOfEmployees

 

NM

O

N

 

 

 

OrganizationInfo-OperatingHourStartTime

 

TM

O

N

 

 

 

OrganizationInfo-OperatingHourStartTime

 

TM

O

N

 

 

 

OrganizationInfo-DataQualityType

 

ST

O

N

 

 

 

OrganizationInfo-ValidFrom

 

DT

O

N

 

 

 

OrganizationInfo-ValidTo

 

DT

O

N

 

 

 

OrganizationInfo-##other

 

ST

O

N

 

 

 

Virtual Table Field Description and Commentary – OrganisationInformation

HL7 Column Name (Query ID=Z08) (Uses HAVE element name)

HL7 Component Name

HL7 Data Type

Description

tableLabel

 

ST

Fixed value: “OrganisationInformation

Identifies HAVE element represented by this table

OrganisationName

 

XON

 

                OrganisationID

XON.10 Organization ID

ST

 

                OrganisationIDType

XON.7 Identifier Type

ID

 

                NameElement

XON.1 Organization Name

ST

HL7 only supports one “NameElement” as Organization Name. (SubDivisionName is not supported.)

Addresses

 

XAD

 

Address-FreeTextAddress -AddressLine[1]

XAD.1.1 Street Address

ST

First Address line

Address-FreeTextAddress -AddressLine[2]

XAD.2 Other Designation

ST

Second address line

(additional address lines are not supported)

Address-Country-NameElement

XAD.6 Country

ID

HL7 uses ISO-3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country codes

Address-AdministrativeArea-NameElement

XAD.4 State or Province

ST

HL7 only supports one “AdministrativeArea” as State

Address-AdministrativeArea-SubAdministrativeArea-NameElement

XAD.9.2 County/Parish.Text

ST

HL7 only supports one “SubAdministrativeArea” as County/Parish

Address-Locality-NameElement

XAD.3 City

ST

HL7 only supports one “Locality” as City

(SubLocalities are not supported)

Address-PostCode-Identifier

XAD.5 Zip or Postal Code

ST

HL7 only supports one “PostCode” as Zip or Postal Code

Address-Locality-SubLocality-NameElement

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

ContactNumbers

 

XTN

 

ContactNumber-CommunicationMediaType

XTN.3 Telecommunication Equipment Type

ID

A limited set of values are represented as codes in HL7.  Relevant values are:

PH           Telephone

FX           Fax

MD          Modem

CP           Cellular or Mobile Phone

SAT         Satellite Phone

BP           Beeper

TDD        Telecommunications Device for the Deaf

TTY         Teletypewriter

ContactNumber-Usage

XTN.2 Telecommunication Use Code

ID

A limited set of values are represented as codes in HL7.  Relevant values are:

PRN        Primary Residence Number

ORN        Other Residence Number

WPN       Work Number

VHN        Vacation Home Number

ASN         Answering Service Number

EMR        Emergency Number

PRS         Personal

ContactNumber-ContactNumberElement

XTN.12 Unformatted Telephone Number

ST

HL7 only supports one iteration of “ContactNumber-ContactNumberElement” as Unformatted Telephone Number

XTN.4 Communications Address and XTN.7 Local Number must NOT be populated

ContactNumber-ContactHours

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

ElectronicAddressIdentifiers

 

XTN

 

ElectronicAddressIdentifier

XTN.4 Communication Address

ST

 

EletronicAddressIdentifer-Type

 

ST

A limited set of values are represented as codes in HL7.  Relevant values are:

Internet   Internet Address

X.400       X.400 email address

EletronicAddressIdentifer-Usage

 

ST

A limited set of values are represented as codes in HL7.  Relevant values are:

WPN       Work Number

PRS         Personal

OrganizationInfo-Type

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-CategoryType

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-Status

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-Nature

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-IndustryType

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-IndustryCode

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-IndustryCodeType

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-NumberOfEmployees

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-OperatingHourStartTime

 

TM

No mapping to HL7 content.  Free text can be supplied in HL7 message

 

HL7 time format:  HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ].

EDXL date-time format: HH:MM:SS[-,+]ZZ:ZZ

OrganizationInfo-OperatingHourStartTime

 

DTM

No mapping to HL7 content.  Free text can be supplied in HL7 message

 

HL7 time format:  HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ].

EDXL date-time format: HH:MM:SS[-,+]ZZ:ZZ

OrganizationInfo-DataQualityType

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-ValidFrom

 

DT

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-ValidTo

 

DT

No mapping to HL7 content.  Free text can be supplied in HL7 message

OrganizationInfo-##other

 

ST

No mapping to HL7 content.  Free text can be supplied in HL7 message

 

B.2.1.5.3 Virtual Table Field definition – Facility

HL7 Column Name (Query ID=Z08) (Uses HAVE element name)

HL7 terms

Length

Data Type

Opt

Rep

Table

HL7 Segment Field

HL7 Element Name

tableLabel

 

ST

R

N

 

 

 

ID

 

ST

R

N

 

 

 

parentID

 

ST

O

N

 

 

 

name

 

ST

R

N

 

 

 

name-alttxt

 

ST

O

N

 

 

 

name-altlang

 

ID

C

N

ISO369

 

 

kind

 

ST

R

N

FacilityKindType

 

 

reportingPeriod

 

DR

O

N

 

 

 

                fromDateTime

 

DTM

R

N

 

 

 

                toDateTime

 

DTM

R

N

 

 

 

lastUpdate

 

DTM

O

N

 

 

 

organizationInformation

 

 

 

 

 

 

Organization record

geolocation

 

 

 

 

 

 

Geolocation record

status-isOK

 

ID

R

N

HL70136

 

 

status-colourCode

 

ST

O

N

ColourCodeDefaultType

 

 

Status-description

 

ST

O

N

 

 

 

Status-description-alttxt

 

ST

O

N

 

 

 

Status-description-altlang

 

ID

O

N

ISO369

 

 

Status-stability

 

ST

O

N

StabilityType

 

 

Status-comment

 

ST

O

N

 

 

 

Status-comment-alttxt

 

ST

O

N

 

 

 

Status-comment-altlang

 

ID

C

N

ISO369

 

 

services

 

 

 

 

 

 

Services record

futureServices

 

 

 

 

 

 

FutureServices record

activityInPeriod

 

 

 

 

 

 

Activity record

operation

 

 

 

 

 

 

Operation record

Operations-comment

 

ST

O

N

 

 

 

Operations-comment-alttxt

 

ST

O

N

 

 

 

Operations-comment-altlang

 

ID

O

N

ISO369

 

 

resourceInformation

 

 

 

 

 

 

Resource-Staff record

staffing

 

 

 

 

 

 

Resource-Staff record

emergencyDepartment

 

 

 

 

 

 

ED record

traumaCenter

 

 

 

 

 

 

TraumaCenter record

Facility-comment

 

 

 

 

 

 

Comment record

Virtual Table Field Description and Commentary – Facility

HL7 Column Name (Query ID=Z08) (Uses HAVE element name)

HL7 Component Name

HL7 Data Type

Description

tableLabel

 

ST

Fixed value: “Facility

Identifies HAVE element represented by this table

ID

 

ST

Xsd:ID

parentID

 

ST

Xsd:IDREF

name

 

ST

 

name-alttxt

 

ST

 

name-altlang

 

ID

 

kind

 

ST

 

reportingPeriod

 

DR

 

                fromDateTime

 

DTM

 

                toDateTime

 

DTM

 

lastUpdate

 

DTM

 

organizationInformation

 

 

Organization record

geolocation

 

 

Geolocation record

status-isOK

 

ID

Y – Yes

N – No

status-colourCode

 

ST

 

Status-description

 

ST

 

Status-description-alttxt

 

ST

 

Status-description-altlang

 

ID

 

Status-stability

 

ST

 

Status-comment

 

ST

 

Status-comment-alttxt

 

ST

 

Status-comment-altlang

 

ID

 

services

 

 

Services record

futureServices

 

 

FutureServices record

activityInPeriod

 

 

Activity record

operation

 

 

Operation record

Operations-comment

 

ST

 

Operations-comment-alttxt

 

ST

 

Operations-comment-altlang

 

ID

 

resourceInformation

 

 

Resource-Staff record

staffing

 

 

Resource-Staff record

emergencyDepartment

 

 

Emergency Department record

traumaCenter

 

 

Trauma Center record

comment

 

 

Comment record

 

B.2.1.5.4 Virtual Table Field definition – Operation

HL7 Column Name (Query ID=Z08) (Uses HAVE element name)

HL7 terms

Length

Data Type

Opt

Rep

Table

HL7 Segment Field

HL7 Element Name

tableLabel

 

ST

R

N

 

 

 

kind

 

ST

R

N

 

 

 

name

 

ST

R

N

 

 

 

name-alttxt

 

ST

O

N

 

 

 

name-altlang

 

ID

C

N

ISO369

 

 

status-isOK

 

ID

R

N

HL70136

 

 

status-colourCode

 

ST

O

 

ColourCodeDefaultType

 

 

Status-description

 

ST

O

 

 

 

 

Status-description-alttxt

 

ST

O

 

 

 

 

Status-description-altlang

 

ID

O

N

ISO369

 

 

Status-stability

 

ST

O