Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 2.0 (2018-12-14)

������������������������������������������������������������������ Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 2.0 Committee Specification 01 Proposed HL7� Informative Document 13 December 2018 Specification URIs This version: https://docs.oasis-open.org/emergency/edxl-have/v2.0/cs01/edxl-have-v2.0-cs01.doc (Authoritative) https://docs.oasis-open.org/emergency/edxl-have/v2.0/cs01/edxl-have-v2.0-cs01.html https://docs.oasis-open.org/emergency/edxl-have/v2.0/cs01/edxl-have-v2.0-cs01.pdf Previous 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 Latest version: https://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.doc (Authoritative) https://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.html https://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 ( [email protected] ), Individual Editors: Darrell O�Donnell ( [email protected] ), Individual Brian Wilkins ( [email protected] ), MITRE Corporation Rex Brooks ( [email protected] ), individual Scott M. Robertson ( [email protected] ), Kaiser Permanente Additional artifacts : This prose specification is one component of a Work Product that also includes: � XML schemas: https://docs.oasis-open.org/emergency/edxl-have/v2.0/cs01/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. 13 December 2018. OASIS Committee Specification 01. Proposed HL7 Informative Document. https://docs.oasis-open.org/emergency/edxl-have/v2.0/cs01/edxl-have-v2.0-cs01.html . Latest version: https://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 [email protected] 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.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 . 115 Appendix C. Revision History . 117 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 Common Alerting Protocol v1.2 specification (EDXL-CAP), with various dedicated profiles The Distribution Element specification v2.0 (EDXL-DE) The Hospital AVailability Exchange specification v1.0 (EDXL-HAVE) The Tracking of Emergency Patients specification v1.1 (EDXL-TEP) The Resource Messaging specification v1.0 (EDXL-RM) The Situation Reporting specification v1.0 (EDXL-SitRep) The Tracking of Emergency Client v1.0 (EDXL-TEC) The primary purpose of EDXL-HAVE is to provide an XML-based reporting format that allows information to be shared about a set of health facilities including the communication of the status of a health facility, its services, and its resources. These include bed capacity and availability, emergency department status, staffing levels, available service coverage, and the status of a health facilities operations and resources. The primary audience for EDXL-HAVE is the broad community that interacts with health facilities and it is intended to be used as a tool to automate information flow in and out of the health network. It is not intended to be a tool used for internal administration of health facilities as other standards organizations (e.g. Health System Level Seven International � www.hl7.org ) already handle this domain. 1.5 History In a disaster or emergency situation, there is a need for hospitals to be able to communicate with each other, and with other members of the emergency response community.� The ability to exchange data in regard to hospitals� bed availability, status, services, and capacity enables both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiency and speed. In particular, it will allow emergency dispatchers and managers to make sound logistics decisions such as where to route victims and automatically determining which hospitals have the ability to provide the needed service.� Many hospitals have expressed the need for, and indeed are currently using, commercial or self-developed information technology that allows them to publish this information to other hospitals in a region, as well as Emergency Operations Centers (EOCs), 9-1-1 centers, and Emergency Medical Systems (EMS) responders via a Web-based tool. The Hospital Availability Exchange standard was created to make sharing information about the state of hospitals for day-to-day and crisis use. Initially it was focused purely on hospitals but it has been extended to handle sharing information about the broader health network, including long-term care facilities, urgent care clinics, and temporary aid centers. HAVE 1.0 was released on 22DEC2009. Since the release of HAVE 1.0 there have been multiple operational uses of HAVE, including after the 2010 Haiti Earthquake. In many of the operational uses there were modified schema used to add services that were not in HAVE 1.0 and to convey other aspects of the data and to handle the sharing of information about non-hospital facilities (e.g. clinics, temporary locations). The use of the HAVE 1.0 standard was encouraging but the shortfalls needed to be addressed. To that end, in 2010 the OASIS EM-TC voted to re-open the HAVE standard with the goal of creating a HAVE 2.0 standard. The HAVE data exchange standard goes hand in hand with the EDXL Tracking of Emergency Patients (TEP).� A TEP-based data exchange collects data on patients from incident EMS first encounter and field hospital triage to EMS transport and patient registration at a definitive care facility such as a hospital emergency room.� It can also be used for the routine transport of patients and for the evacuation of hospitals involving EMS transport and care.� In all scenarios, it relieves the heavy administrative burden levied on staff to re-key patient information, often after the fact, enabling automatic and pro-active hospital preparedness.� In September of 2016, a bidirectional transformation specification between TEP and HL7 messaging was completed.� This enables the transformation of the TEP data taken by emergency response to automatically populate in hospital data systems.� HAVE supports the TEP standard by providing the data needed about available hospital resources to enable the informed routing decisions needed by EMS.� In this way, the patients can be routed to the hospital with the facilities needed to support their needs.� Given the TEP, the emergency room will be able to see the data about the incoming patient in order to best prepare for their optimal care.� Both of these initiatives began with the Department of Homeland Security Science and Technology (DHS S&T) effort to identify the next most important data standards needed for emergency response.� Practitioners in both the medical and emergency management domains were included in developing draft specifications after many facilitated sessions to include scenario working groups. The National Association of Emergency Medical Services Officials (NASEMSO) is one organization that participated in the DHS S&T effort.� In October 2015, NASEMSO issued a resolution to encourage the completion and implementation of the TEP and HAVE standards.� The DHS S&T effort concluded with two live exercises utilizing both TEP and HAVE (see next section). The HAVE 2.0 will be coordinated with HL7 through the work of the Patient Administration Work Group.� OASIS and HL7 intend to release a joint specification for the HAVE Standard under the Statement of Understanding between the organizations.� The effective exchange and common data interoperability will enable both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiently and speed.� The TEP and HAVE Standards Have Been Proven Successful in Live Exercises The draft TEP standard was successfully implemented by four independent systems: Tennessee�s state EMS system and a local EMS system in Memphis, the state of Maryland EMS system, and the federal JPATS system.� The Integrated Public Alerts and Warnings System (IPAWS) was plugged in as the message broker (the �post office� that routes data traffic where users need). �State, local and federal agencies proved that these standards-based data exchanged work by plugging into existing major live-actor patient movement exercises at disaster sites, aircraft bases and hospitals. During a 2010 National Disaster Medical System (NDMS) patient movement exercise in Tennessee, data following patient movement from Maryland to Tennessee was exchanged in real time between the Maryland EMS system to JPATS then to the Tennessee State and Memphis EMS systems.� All systems displayed the current data as if updates were completed directly in their system.� EM Systems was used to compile and aggregate HAVE data from 3 different hospitals, which was used by emergency managers to route patients to the most appropriate destinations with the availability, capabilities and staff to provide care. Simultaneously with the FEMA National Level Exercise (NLE) in 2011, five states cooperated to track patient movement across them employing five different patient tracking systems.� All systems, some commercially available and some home-grown, were able to track the data updates in their own systems. At the 2012 Integrated Medical, Public Health, Preparedness and Response Training Summit, presenters from the DHS S&T Practitioner Steering Group moved volunteer patients through the room to different �states� and were able to display data updates across four independent systems including JPATS. In these exercises and the 2012 demonstration, as each existing system automatically scanned, entered or updated patient data, that data was automatically shared in near real-time behind the scenes with no manual intervention, allowing users to view and report data in their own systems as if all data updates were made there. Using an aggregation of multiple hospital HAVE reports, emergency managers were able to route patients to appropriate destinations. 1.6 Structure of the EDXL Hospital Availability Exchange Specification The EDXL-HAVE 2.0 standard document structure is defined using successively more detailed or constrained artifacts in the form of textual descriptions, diagrams, figures, tables and Appendices. The EDXL-HAVE XML Schema is provided separately. The overall structure of the EDXL-HAVE report is first represented in an Element Reference Model (ERM). The ERM is the foundation from which individual constraint schemas (individual situation report types) are defined. The structure of the EDXL-HAVE standard is defined in the following sections: Section 2 summarizes the design principles of the standard and shows several usage scenarios; Section 3 provides and informal overview of EDXL-HAVE. In particular: Section 3.1 presents an extensive definition of a HAVE report; Section 3.2 describes essential supporting elements in the EDXL Common Types collection, including the use of EDXL Extensions; Section 3.3 presents the Element Reference Model (ERM) which shows the abstract structural relationships of the main components of EDXL-HAVE; Section 3.4 discusses how the distribution requirements for EDXL-HAVE messages may be met through several mechanisms, including EDXL-Distribution Element (DE) and as general data payloads; Section 3.5 presents a summary of the elements that make up a HAVE message. Section 4 The Data Dictionary formally defines each element contained in the EDXL-HAVE standard message. Section 5 provides conformance information. These sections together define the message structure, message element definitions, optionality and cardinality. 2 Design Principles & Concepts (non-normative) Below are some of the guiding principles behind the development of EDXL-HAVE: Support day-to-day and crisis use of the standard. Facilitate sharing of information amongst the general public, all levels of government, first nation/tribal, international, and non-governmental organizations. Provide a simple information report that allows first responders, emergency managers, community leaders, politicians, and other stakeholders to get a quick glimpse of the state of the health network in a community. Provide a non-invasive way for a health facility to keep the communities that they serve abreast of developments that impact their ability to provide care. Be respectful of the boundaries of internal health facility information and the information that is relevant externally. Separation of EDXL-HAVE reports from being tied to a particular method of delivery. Use and reuse of data, content, and models developed by other initiatives that align with EDXL-HAVE. Provide a baseline set of services, operations, and resources to allow health facilities to start using HAVE quickly, while allowing for controlled extension where warranted. 2.1 Requirements for Design The OASIS EM-TC tasked the EDXL-HAVE Sub-committee to review HAVE 1.0 and propose Errata, Minor, and Major versions. The initial tasking provided the following guidance: Figure 1 - EM EDXL-HAVE SC Scope 2.2 Example Usage Scenarios The following scenarios illustrate how EDXL-HAVE 2.0 can be used in the field. 2.2.1 Day-to-Day � Dialysis Patient: On a routine pickup a social worker picks up an elderly patient that needs routine maintenance. Normally the dialysis is performed at the closest facility, but the social worker knows that the small facility�s dialysis unit is not operating due to an equipment failure. A quick query to view the local health facilities presents several within a 20-minute drive, so the social worker places a call and coordinates with one of the alternate facilities. 2.2.2 First Responder � Responding with Critical Care As the result of a multi-unit residential fire, ambulances are dispatched and the Incident Commander indicates that there are 2 critical and 3 serious burn victims. The nearest hospital can only take in 2 burn victims normally, but the current state of the burn unit is not known. By examining the state of the local facilities, officials can coordinate which victims are to be taken to the surrounding health facilities. 2.2.3 Mass-Scale Vaccination Clinics Under pandemic conditions a community is implementing a vaccination program with the hospitals, urgent care clinics, private clinics, and temporary clinics providing vaccinations. The public, key officials, and the media can have immediate visibility into the wait times and service availability at each of the vaccination sites. EDXL-HAVE provides the ability to display service availability for each facility, referenced on a map, by colour code and to provide an indication of wait times if they are available. 2.2.4 Disaster Response: Following a major earthquake in the developing world, NGOs, various government responders, and local officials (and non-officials) establish temporary health-care facilities to meet the urgent and non-urgent health needs of those injured or killed by the earthquake and ensuing issues. Coordination of multiple dimensions are critical: what services are available, what is the capacity of the facilities, what resources they are missing or can share, where are the facilities located, who are the official points of contacts, what agency is running the facility, what are the hours operation, etc.� As the event unfolds there is a Cholera outbreak due to damaged sanitation. There is a clear need identified to track 2 particular services (e.g. Cholera Vaccination and Cholera Treatment) that were too specific to be part of the default HAVE 2.0 services taxonomy. After a meeting of the coordinating agencies, the data being shared is extended to include Cholera Vaccination and Cholera Treatment services, including the standard metrics (capacity, colour code for status, etc.) 3 EDXL HAVE Section 3 of this Standard is normative unless otherwise stated . If any differences are found between any XML schema and its associated model, diagram, table or other artifact or text, then the XML schema shall always take precedence and the other artifact(s) must be changed to match the XML schema. Note: Please report any such errors to OASIS. 3.1 HAVE Report Definition (non-normative) The HAVE Report is a single EDXL message that is intended to provide sharing of the services, operations, and capacities of health facilities. Health facilities in HAVE include hospitals, urgent care clinics, temporary facilities, and other facilities that may provide health services for a community. Typical actors: Senders � hospital administrators, hospital networks, health providers, NGOs, clinic administrators, and emergency medical services, etc. Recipients � first responders, dispatch operators, emergency managers, automated systems, etc. 3.2 Supporting Elements (non-normative) 3.2.1 Common Types Supporting Element Types borrow re-usable elements from the EDXL Common Types (ct:) that apply to and support multiple areas of the HAVE 2.0 reports, such as Location. For instance incidentLocation relies on ct:EDXLLocationType, which consists of either EDXLGeoLocation for geographical information or EDXLGeoPoliticalLocation for geopolitical information. EDXLGeoLocation is of type edxl-gsf:EDXLGeoLocationType and EDXLGeoPoliticalLocation is of type ct:EDXLGeoPoliticalLocationType. This latter type consists of either a GeoCode (of type ct:ValueListType) or an Address (of type edxl-ciq:xAL:AddressType). The following elements are used in this specification and can be found at the locations cited in the normative references in Section 1.2 of this document. Supporting Element/Type Defined In ct:EDXLDateTimeType EDXL-CT (Simple Types) ct:EDXLStringType EDXL-CT (Simple Types) ct:ValueListURIType EDXL-CT (Simple Types) ct:ValueType EDXL-CT (Simple Types) ct:ValueListType EDXL-CT (Complex Types) ct:ValueKeyType EDXL-CT (Complex Types) ct:EDXLGeoPoliticalLocationType EDXL-CT (Complex Types) ct:EDXLLocationType EDXL-CT (Complex Types) gsf:EDXLGeoLocationType EDXL-GSF ct:ValueListURI EDXL-CT (Top Level Elements) xal:addressType EDXL-CIQ Some elements of the common type �ct:EDXLStringType� are denoted as [token] in the accompanying XML per the following reference: [token] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#token, W3C REC-xmlschema-2, October 2004. The definition for token as found in the OASIS common types is: � The value space of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces. � The implication is that the XML parser will change string entries to remove c arriage returns, line feeds, tab characters, leading or trailing spaces, and internal sequences of two or more spaces. 3.2.2 Selecting Values from Lists The ValueList and ValueKey types are part of the EDXL Common Types collection. They allow standards adopters to use topic specific lists of values for elements such as externalCode alternateCodeValue, etc.. Both types have identical structure, but ValueList allows for selection of multiple values [1..*] in the list, whereas ValueKey allows for selection of only one [1..1] value in the list. When using a ValueList / ValueKey structure the user can specify a user-defined list by URI (either using the �urn:...� format or the more familiar �http://...� format) and then include user-defined values from that list. This structure has several advantages: (a) it provides flexibility for local communities to use community-defined terms and vocabulary; (b) it allows for the external maintenance of local or standardized lists; and (c) it avoids the problems inherent in attempting to constantly update hard-coded enumerations in a specification. An existing vetted list should be referenced for defaults, but users could also reference their own value list 3.2.3 ValueKeyType The schema for ValueKeyType is defined as <xs:complexType name="ValueKeyType"> <xs:sequence> <xs:element ref="ct:ValueListURI" minOccurs="1" maxOccurs="1"/> <xs:element ref="ct:Value" minOccurs="1" maxOccurs="1"/> </xs:sequence> </xs:complexType> and its application to the XML description of an element elementName of type ct:ValueKeyType would be: < elementName > <ct:ValueListURI> valueListURI </ct:ValueListURI> <ct:Value> value </ct:Value> </ elementName > This example uses a published list of values and definitions and selects one specific entry to describe a resource need of a facility: valueListURI = https://www.medwish.org/give/medical-supplies/ value = Bandages which stands for <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: Standard augmentation: community adds new information that is associated with the EDXL standard. Examples: adding HL7 translation information to the HAVE payload. List augmentation: community adds new values (enumerations) to the default set of values in the standard. Example: adding community-specific information to the ServiceType element. In HAVE 2.0, �Extensions� are used under the following elements: ServiceType ResourceInformationType OperationType OffloadInfoType TraumaCenterLevelType The schema for Extension is defined as <xs:element name="extension"> ����������� <xs:complexType> ����������������������� <xs:sequence> ����������������������������������� <xs:element name="community" type="xs:anyURI" /> ����������������������������������� <xs:element name="id" type="xs:anyURI /"> ����������������������������������� <xs:element name="parameter" type="ext:ParameterType" maxOccurs="unbounded"/> ����������������������� </xs:sequence> ����������� </xs:complexType> </xs:element> and its application to the XML description of an extension would be: < extension > ����� < community >communityURI</ community > < id > idURI </ id > < parameter > ����������� < nameURI >nameURI</ nameURI > ����������� < value >some value</ value > </ parameter > </ extension > This example uses a qualify for status stability for a service: community = facility:service:status:refined id = extension:1 parameter-nameURI = have:service:status parameter-value = Rapidly which stands for <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 ( reportingPeriod � optional ) that identifies reporting period applicable for this HAVE report, and a group of elements ( facility � required ) that uniquely identifies and describes the facility�s status including � facility name and location, � overall facility status, .. � services, .. � operations, .. � resources, .. � staffing, .. � and emergency department. These elements are detailed further in the Element Reference Model (Section 3.3) and in the Data Dictionary (Section 4). 4 Data Dictionary This Data Dictionary specifically references the document EDXL_HAVE_Requirements_12232005 publicly available at https://www.oasis-open.org/committees/document.php?document_id=16400&wg_abbrev=emergency � This is the source to which the �Requirements Supported� row in each element entry refers. Since the Requirements are numbered, we cite the Requirement number that the entry supports. 4.1.1 HAVE Element HAVE Type �xs:complexType Usage REQUIRED , MUST be used once and only once Definition Top Level item for Hospital AVailability Exchange (HAVE) message. Comments � Provides context to the HAVE report Sub-elements � organizationInformation � reportingPeriod � facility � remarks Requirements �Supported Requirement Number 1. Element organizationInformation Type OrganizationInformationType [xpil:OrganisationDetailsType] Usage REQUIRED , MUST be used once and only once Definition Information of the Organization that is responsible for the reporting of these facilities. Comments � Based on [xpil:OrganisationDetailsType] Constraints Specific information includes: � OrganisationName � Addresses � ContactNumbers � ElectronicAddressIdentifiers � OrganisationInfo Requirements �Supported Requirement Numbers 1,� 2. Element reportingPeriod Type �edxl-ct:TimePeriodType Usage OPTIONAL, MAY be used once and only once Definition The reporting period applicable for the HAVE root element and called the "current reporting period" typically a 24-hr period but the duration may change for operational reasons. If blank the assumption is that the file is for "today" - local to the issuer. Comments � Constraints Must use � fromDateTime � toDateTime Requirements �Supported Requirement Numbers 1,� 8. Element facility Type FacilityType Usage REQUIRED , MAY be used more than once Definition A list of facilities that comprise the detail of this HAVE message. Comments � Constraints � Requirements �Supported Requirement Numbers 1,� 3. Element remarks Type � edxl-ct:RemarksType Usage OPTIONAL , MAY be used more than once Definition Provides context to the HAVE report. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19. Attribute defaultLanguage Type xs:string Usage REQUIRED , MUST be used once and only once Definition Tag specifying the language that is used throughout the document. Tag MUST comply RFC3066. Free text within the document will be assumed to be in this defaultLanguage. Example: �en_US� Comments � Constraints � Requirements �Supported Requirement Number 1. 4.1.2 FacilityType Element FacilityType Type xs:complexType Usage REQUIRED , MUST be used once and only once. Definition The set of information details that define a facility.. Comment � Sub-elements � name � kind � reportingPeriod � lastUpdate � organizationInformation � geoLocation � status � services � futureServices � activityInPeriod � operations � resourceInformation � staffing � emergencyDepartment � traumaCenter � remarks Requirements Supported Requirement Numbers 1,� 3. Element name Type �FreeTextType [LimitedString (restriction base: xs:string)] Usage REQUIRED , MUST be used once and only once Definition Name of facility. Comments � Constraints � Requirements �Supported Requirement Numbers 1,� 3. Element kind Type FacilityKindType Usage REQUIRED , MUST be used once and only once Definition The kind of facility (e.g. Hospital, Long Term Care, Seniors Residence, Temporary Clinic). Comments � Constraints � Requirements �Supported Requirement Numbers 1,� 3. Element reportingPeriod Type �edxl-ct:TimePeriodType Usage OPTIONAL, MAY be used once and only once Definition The reporting period applicable for this Facility element and the "current reporting period" typically a 24-hr period but the duration may change for operational reasons. If this value is not provided the HAVE message reporting period will be assumed. Comments � Constraints Must use � fromDateTime � toDateTime Requirements �Supported Requirement Numbers 1, 8. Element lastUpdate Type edxl-ct:EDXLDateTimeType Usage OPTIONAL, MAY be used once and only once Definition The reporting period applicable for this HAVE report and called the "current reporting period" typically a 24-hr period but the duration may change for operational reasons. If blank the assumption is that the file is for "today" - local to the issuer Comments � Constraints � Requirements �Supported Requirement Numbers 1,� 8. Element organizationInformation Type �xpil:OrganisationDetailsType Usage REQUIRED , MUST be used once and only once Definition Administrative and Organizational information about the Facility. Comments � Constraints � Requirements �Supported Requirement Numbers 1,� 2. Element geoLocation Type GeoLocationType (restriction base: edxl-gsf:EDXLGeoLocationType) Usage REQUIRED , MUST be used once and only once Definition The single geometry that represents the Facility location. A WGS84 SRS element is mandatory. Alternate SRS geometry elements can be provided. If alternate geometry elements are provided they should reflect the same physical location. Comments � MUST include a <wgs84Location> element � SRS attribute MUST be � http://www.opengis.net/def/crs/EPSG/0/4326 �. � MAY include one or more <geoLocationExtended> elements. Constraints � Requirements �Supported Requirement Numbers 1, 10. Element status Type �StatusType Usage REQUIRED , MUST be used once and only once Definition The overall status of the Facility. This value is intended to provide a high-level summary status of the Facility from the perspective of the person responsible for the Facility. The particulars driving that Facility status should be provided where appropriate (Services, Operations, etc.). Comments (comment element) should be used to provide only the high-level summary. Comments � Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type Constraints � Requirements �Supported Requirement Numbers 1, 3, 11, 15, 16, 17, 18. Element services Type ServicesType Usage REQUIRED , MUST be used once and only once Definition Container element of all the elements of service coverage. This includes both the necessary staff and facilities. Indicator of the availability of specialty service coverage. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18. Element futureServices Type �FutureServicesType Usage OPTIONAL , MAY be used more than once Definition Optional list of Service Capabilities in future for planned or ramping up (or down) of capabilities to accomodate surge needs or degraded capabilities. 0...n Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18. Element activityInPeriod Type ActivityInPeriodType Usage OPTIONAL , MAY be used more than once Definition Provides a set of summaries of activity that has occured in the indicated reporting period. This item is intended to provide a very high-level of facility activity. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 5, 8, 11, 15, 16, 17, 18. Element operations Type �OperationsType Usage OPTIONAL, MAY be used more than once Definition Provides a taxonomy-based list of operations that describe the operations of the Facility. Operations are the inward-facing capabilities that a Facility requires to run (e.g. HVAC, power, quarantine, Emergency Operations Centre). Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3. Element resourceInformation Type ResourceInformationType Usage OPTIONAL, MAY be used more than once Definition Staffing provides an indication of the staffing status and any needs or offers of this facility. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17, 18. Element staffing Type �ResourceInformationType Usage OPTIONAL , MAY be used more than once Definition Staffing provides an indication of the staffing status and any needs or offers of this facility. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 17, 18. Element emergencyDepartment Type EmergencyDepartmentType Usage OPTIONAL, MAY be used once and only once Definition Report on the emergency department status for the organization. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11. Element traumaCenter Type �TraumaCenterType Usage OPTIONAL, MAY be used once and only once Definition Type of the trauma center for the organization. Comments � Constraints � Requirements �Supported Requirement Numbers 1,� 3, 11, 17. Element remarks Type �edxl-ct:RemarksType Usage OPTIONAL , MAY be used once and only once Definition Provides context to the FacilityType.. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19. Attribute ID Type xs:ID Usage REQUIRED , MUST be used once and only once Definition A unique identifier for this Facility. This value should be unique globally, but MUST be unique from the sender perspective. Comments � Constraints � Requirements �Supported Requirement Number 1, 3. Attribute parentID Type �xs:IDREF Usage OPTIONAL , MAY be used once and only once. Definition Reference to the ID of the Facility that is the parent (owner, manager, responsible, etc.) of this Facility. This field is optional and used to provide hierarchy for formal facility organizations. Comments � Constraints � Requirements �Supported Requirement Number 1, 3. 4.1.3 BedCapacityType Element BedCapacityType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Top level complex schema type defining bed capacity counts (available/baseline) given a specific type of bed. Comments � Constraints � Sub-elements � availableCount � baselineCount � comment Requirements �Supported Requirement Number 1, 13, 14. Element availableCount Type �xs:integer Usage REQUIRED , MUST be used once and only once Definition The number of vacant/available beds to which patients can be immediately supported. These must include supporting space, equipment, medical material, ancillary and support services and staff to operate under normal circumstances. These beds are licensed, physically available and have staff on hand to attend to the patient who occupies the bed. NEGATIVE values means the service is operating beyond normal capacity. Comments � Constraints � Requirements �Supported Requirement Number 1, 13, 14. Element baselineCount Type xs:integer Usage OPTIONAL, MAY be used once and only once Definition The maximum (baseline) number of beds in this category. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 13, 14. Element remarks Type �edxl-ct:RemarksType Usage OPTIONAL , MAY be used once and only once Definition Provides context for the BedCapacityType. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19. 4.1.4 StabilityType Element StabilityType Type xs:simpleType (restriction base: xs:string) Usage REQUIRED , MUST be used once and only once Definition Indication of stability - positive/improving, negative/deteriorating, neutral/stable. Comments � Constraints MUST use one of the following values: � stable -- Stable/unchanging - conditions remain within norms and are not out of normal patterns � improving -- Conditions are improving towards normal � deteriorating -- Conditions are deviating negatively from normal Requirements �Supported Requirement Numbers 1, 2, 3, 4, 6, 11, 15, 16, 17, 18. 4.1.5 OffLoadKind Element Element OffLoadKind Type �xs:simpleType (restriction base: xs:token) Usage REQUIRED , MUST be used once and only once Definition MUST use one of the following values: � land � air � other Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. 4.1.6 OffloadStateKind Element Element OffloadStateKind Type xs:simpleType (restriction base: xs:token) Usage REQUIRED , MUST be used once and only once Definition MUST use one of the following values: � normal � delayed Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. 4.1.7 OffloadType Element OffloadType Type �xs:complexType Usage REQUIRED , MUST be used once and only once Definition Indicator of offload times of ambulance capabilities. The time it takes transfer care of a patient to hospital staff, thereby freeing the transport for assignment. Comments � Constraints � Sub-elements � kind � offloadMinutes � offloadState � offloadColourCode � remarks Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element kind Type OffloadKind [xs:simpleType (restriction base: xs:token)] Usage REQUIRED , MUST be used once and only once Definition The mode of transport for offload (land, air, other). Comments � Default: land Constraints MUST use one of the following values: � land � air � other Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element offloadMinutes Type �xs:integer Usage REQUIRED , MUST be used once and only once Definition Average offload time in minutes. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element offloadColourCode Type �ColourStatusType Usage OPTIONAL , MAY be used once and only once Definition Colour (text-based) of the Offload capabilities status. By default triage colours of green, yellow, orange, red, black are supported. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MAY be used once and only once Definition Provides context to the OffloadType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19. 4.1.8 OrganizationInformationType Element OrganizationInformationType Type �xs:complexType [xpil:OrganisationDetailsType] Usage REQUIRED , MUST be used more than once Definition The container element for organization information elements. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 9, 10. 4.1.9 StatusType Element StatusType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Complex Type to provide status information: OK (yes/no), colour code, Stability, and commentary. Comments � Constraints � Sub-elements � isOK � colourStatus � stability � comments Requirements �Supported Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17. Element isOK Type �xs:boolean Usage REQUIRED , MUST be used once and only once Definition Is the service/capability available/functioning/adequate?� True = yes, false = no. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17. Element colourStatus Type ColourStatusType Usage OPTIONAL , MAY be used once and only once Definition Colour (text-based) of the status. By default triage colours of green, yellow, orange, red, black are supported. Element colourStatus can apply to Facility, Services, and Operations. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17. Element stability Type �StabilityType Usage OPTIONAL , MAY be used once and only once Definition Indication that the Status is stable, improving, or deteriorating Comments � Constraints MUST use one of the following values: � stable -- Stable/unchanging - conditions remain within norms and are not out of normal patterns � improving -- Conditions are improving towards normal � deteriorating -- Conditions are deviating negatively from normal Requirements �Supported Requirement Numbers 1, 3, 4, 11, 12. 15, 16, 17. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MAY be used once and only once Definition Provides context to the OffloadType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19. Element comments Type FreeTextType Usage OPTIONAL , MAY be used once and only once Definition Provides context to StatusType. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 17, 19. 4.1.10 ServiceType Element ServiceType Type �xs:complexType Usage REQUIRED , MUST be used once and only once Definition Extensible Service Type for providing detail on a health Service that the Facility provides Comments � Constraints � Sub-elements � name � code � status � externalCode � bedCapacity � capacity � remarks � ref="ext:extension Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element name Type FreeTextType [LimitedString (restriction base: xs:string)] Usage REQUIRED , MUST be used once and only once Definition The human-readable name of the service that is being described. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17. Element code Type �xs:simpleType (restriction base: ServiceCodeDefaultType) Usage REQUIRED , must be used once and only once Definition See ServiceCodeDefaultType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17. Element status Type StatusType Usage REQUIRED , MUST be used once and only once Definition Describes the status of the service. Comments � Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type. Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element externalCode Type �edxl-ct:ValueKeyType Usage OPTIONAL , MAY be more than once Definition Allows an external system to place its own equivalent code for the service.code value. This allows external systems to correlate their data directly in the HAVE report. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17. Element bedCapacity Type BedCapacityType Usage OPTIONAL , MUST be used once and only once Definition An indication of the bed capacity that the facility makes available for the community to know. It reflects fully staffed and equipped beds. intention here is to provide an external view of where beds may be available in health network. The intent is not for HAVE to become a hospital administration tool. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 13, 14. Element capacity Type �CapacityType Usage OPTIONAL , MAY be used once and only once Definition Indicates the capacity status of this particular service.. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 13, 14. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MAY be used once and only once Definition Textual description of Service situation. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 13, 14, 17, 19. Element ext:extension See Section 3.2.4 EDXL Extensions Type � Usage OPTIONAL , MAY be used more than once Definition Provides extensibility for adding elements to the ServiceType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 14, 16. 4.1.11 ResourceInformationType Element ResourceInformationType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Complex Type to be used for tracking Resource state (status, needs, offers). Allows extension to handle specific information that is non-HAVE (e.g. NIEM payloads, lookups for interoperability with other systems). Comments � Constraints � Sub-elements � status � needs � offers � remarks � ext:extension Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17, 18. Element status Type StatusType Usage REQUIRED, MUST be used once and only once. Definition Overall resource status of the facility. Comments � Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type. Constraints � Requirements Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element needs Type ResourceQuantityType Usage OPTIONAL , MUST be used once and only once Definition Resource Needs. Comments � Uses <resourceNeeds>element Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element resourceNeed Type �ResourceQuantityType Usage OPTIONAL , MAY be used once and only once Definition Identifies a need for a particular resource. Comments � Used by <needs> element Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element offers Type ResourceQuantityType Usage OPTIONAL , MAY be used once and only once Definition Resource Offers (resources that can be made available to other Facilities). Comments � Uses <resourceOffers> element Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element resourceOffer Type �ResourceQuantityType Usage REQUIRED , MAY be used more than once Definition Indicates the amount of this particular resource on offer. Comments � Used by <offers> element Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MUST be used once and only once Definition Provides context for the ResourceInformationType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 5, 6, 11, 13, 14, 17, 19. Element ext:extension See Section 3.2.4 EDXL Extensions Type � Usage OPTIONAL , MAY be used more than once Definition Used to add elements to the ResourceInformationType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 14, 16. 4.1.12 ResourceQuantityType Element ResourceQuantityType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Type for stating a quantity of a particular kind of resource. Comments � The examples below for resourceKind, quantity, and resourceSize reflect the availability (or request) for 4 Boxes of Small Gloves (200 gloves in each box). Constraints � Sub-elements � resourceKind � quantity � resourceSize � remarks Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element resourceKind Type �edxl-ct:ValueKeyType Usage REQUIRED , MUST be used once and only once Definition The kind (type) of resource that the quantity refers to. (e.g. �Latex Gloves�) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element quantity Type xs:double Usage OPTIONAL , MUST be used once and only once Definition The quantity of the particular Resource. (e.g. �4 boxes�) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element resourceSize Type �ext:ParameterNameType Usage REQUIRED , MAY be used once and only once Definition Quantity and Unit of measure (e.g. �Box of 200 Size Small�) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MUST be used once and only once Definition Textual description of Resource quantity. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. 4.1.13 ColourStatusType Element ColourStatusType Type �xs:complexType Usage OPTIONAL , MAY be used once and only once Definition Type that allows the structured use of colour-codes to portray state. Comments � Constraints � Sub-elements � colourCode � statusDescription Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element colourCode Type ColourCodeDefaultType Usage REQUIRED , MUST be used once and only once Definition Colour (text-based) of the status. By default triage colours of green, yellow, orange, red, black are supported. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element statusDescription Type �FreeTextType [LimitedString (restriction base: xs:string)] Usage OPTIONAL , MAY be used once and only once Definition Human-readable text describing the reason for selection of the particular colour-code. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17. 4.1.14 ServiceCodeDefaultType Element ServiceCodeDefaultType Type xs:simpleType (restriction base: edxl-ct:ValueType) Usage REQUIRED , MUST be used once and only once Definition Enumerated list of default service codes Comments � Constraints � Sub-elements � airborneInfectionIsolation � burnUnit� (Burn Center services.) � cardiology (Cardiology services.) � cardiology.invasive (Cardiology with invasive capabilities.) � cardiology.noninvasive (Cardiology with NO invasive capabilities.) � cardiologymi.STEMI (STEMI support.) � cardiologymi.nonSTEMI (NO STEMI support.) � cardiology.telemetry (For remote monitoring of cardiology telemetry data for patient.) � dialysis (Dialysis services.) � emergencyDepartment � hyperBaricChamber (Hyperbaric Chamber) � infectiousDisease (Infectious Disease Service.) � intensiveCare.adult (Adult ICU services.) � intensiveCare.neonatal (Neonatal Intensive Care Unit (ICU) services.) � intensiveCare.pediatric (Pediatric Intensive Care Unit (ICU) services.) � intermediateCare (For low-risk, chronically or critically ill patients.) � neonatology (Neonatology) � neurology (Neurology Services.) � neurology.invasive� (Neurology-Invasive services, including invasive catheterization.) � neurology.noninvasive (Neurology-Non-Invasive services with no invasive catheterization capability.) � obgyn (OBGYN services.) � obgyn.withLaborDelivery (OBGYN with labor delivery.) � obgyn.withoutLaborDelivery (OBGYN without labor delivery capabilities.) � operatingRooms � ophthalmology (Opthalmology services.) � orthopedic (Orthopedic services.) � pediatrics (Pediatrics services.) � psychiatric (Psychiatric services.) � surgery (Surgery capabilities.) � surgery.adultGeneral (General Adult surgery capabilities.) � surgery.pediatrics (General Pediatric surgery capabilities.) � surgery.orthopedics (Orthopedic surgery capabilities.) � surgery.neurosurgery (Neurosurgery capabilities.) � surgery.facial (Facial surgery capabilities.) � surgery.cardiothoracic (Cardiothoracic surgey capabilities.) � surgery.hand (Hand surgery capabilities.) � surgery.reimplantation (Reimplantation surgery capabilities.) � surgery.spinal (Spinal surgery capabilities.) � surgery.vascular (Vascular surgery capabilities.) � surgery.anesthesia (Anesthesia services.) � traumaCenter (TraumaCenter.) Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 12, 14, 15, 16, 17. 4.1.15 CapacityType Element CapacityType Type �xs:complexType Usage REQUIRED , MAY be used once and only once Definition Extensible list (name/value pair) for Service capacity. See the HAVE 2.0 standard document for a suggested list of capacities. Comments � Constraints � Sub-elements � capacity � capacityURI Requirements �Supported Requirement Numbers 1, 13, 14. Element capacity Type ext:ParameterValueType Usage OPTIONAL , MUST be used once and only once Definition An indication of the maximum availability of a measureable resource. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 13, 14. Element capacityURI Type �edxl-ct:ValueListURIType Usage OPTIONAL , MAY be used once and only once Definition A reference to more detailed information about the capacity of the service. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 13, 14. 4.1.16 TriageCountType Element TriageCountType Type xs:complexType Usage OPTIONAL , MAY be used once and only once Definition The number of each triage patient type the overall hospital currently has by colour code Comments � Constraints � Sub-elements � code � count � alternateCodeValue � comment Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element code Type �TriageColourCodeType Usage OPTIONAL , MAY be used once and only once Definition Triage Colour Codes (RED, YELLOW, GREEN, BLACK, none) for capacity purposes. The list of values must be from the list identified in TriageCodeListURN. Default Values red: Number of victims with immediate needs yellow: Number of victims with delayed needs green: Number of victims with minor needs black: Number of deceased victims. Comments � Constraints � If a TriageCountType/code value is specified, a TriageCountType/count element must be specified. Requirements �Supported Requirement Numbers 1, 6. Element count Type xs:int Usage OPTIONAL , MAY be used once and only once Definition The number of patients of this code type. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element alternateCodeValue Type �edxl-ct:ValueKeyType Usage OPTIONAL , MAY be used once more than once Definition There are a large number of Triage systems in use. Many use numbering systems (http://en.wikipedia.org/wiki/Triage#Tags) and colours. The premise of HAVE is that we will share the general state with the broad emergency community who may not know the intimate details of a triage system, but understand the general concepts that Red=urgent, Green=walking wounded, Black=Dead/Lost (already dead or untreatable). The alternateCodeValues element is intended to be used by these systems. Providing the ValueListURI and Value will mapping of external systems to the base HAVE Triage colour codes. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 6. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MUST be used once and only once Definition Provides context for the TriageCountType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. 4.1.17 ActivityInPeriodType Element ActivityInPeriodType Type �xs:complexType Usage OPTIONAL , MAY be used once and only once Definition ActivityInPeriodType gathers information about the admissions, discharges, and deaths in a time period Comments � Constraints � Sub-elements � reportingPeriod � admissions � discharges � deaths � remarks Requirements �Supported Requirement Numbers 1, 8. Element reportingPeriod Type edxl-ct:TimePeriodType Usage OPTIONAL, MAY be used once and only once Definition The time period (From -- To) that the activity occured in. If this element is not included the reportingPeriod at the Facility level should be assumed to define the time range. Comments � Constraints Must use � fromDateTime � toDateTime Requirements �Supported Requirement Numbers 1, 8. Element admissions Type xs:int Usage REQUIRED , MUST be used once and only once Definition Number of admissions in the period. Comments � Constraints � Requirements Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element discharges Type xs:int Usage REQUIRED , MUST be used once and only once Definition Number of Discharges in the period. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element deaths Type xs:int Usage REQUIRED , MUST be used once and only once Definition Number of Deaths in the period. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MAY be used once and only once Definition General comment/summary of the activity in period. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. 4.1.18 TriageColourCodeType Element TriageColourCodeType Type xs:simpleType Usage REQUIRED , MUST be used once and only once Definition MUST use one of the following values � red (RED Triage - Immediate attention for Triage.) � yellow (YELLOW Triage - Needs medical attention after RED/Immediate.) � green (GREEN Triage - Walking wounded or self-treatable.) � black (BLACK Triage - Lost/Dead.) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. 4.1.19 FreeTextType Element FreeTextType Type LimitedString Usage REQUIRED , MUST be used once and only once Definition A restricted text block for preserving whitespace but limiting length to 1024 characters based on the �LimitedString� type. Intended to discourage lengthy descriptions. Comments � Constraints � Sub-elements � defaultText � alternateText Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element defaultText Type LimitedString Usage REQUIRED , MUST be used once and only once Definition Text in the language specified by the HAVE message�s defaultLanguage attribute. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. Element alternateText Type AlternateTextType Usage OPTIONAL , MAY be used more than once Definition Text in alternate language, for use when the language is other than that specified by the defaultLanguage tag of the root HAVE element. Comments � Supports multiple languages in addition to the default language of the HAVE message. � The meaning of the alternateText should be a translation of the defaultText element. Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. 4.1.20 AlternateTextType Element AlternateTextType Type xs:complexType Usage See Usage for elements of type AlternateTextType. Definition Allows for non default language to be used and is a LimitedString language attribute for this element. Attribute value for language MUST comply with RFC3066. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11. 4.1.21 FacilityOperationKind Element Element FacilityOperationKind Type xs:simpleType (restriction base: xs:token) Usage REQUIRED , MUST be used once and only once Definition Must use one of the following: � plant� (Plant - the key equipment and capabilities needed to operate the facility (e.g. HVAC, cafeteria).) � security� (Security operations for facility (e.g. patrol, surveillance).) � staffing� (Staff-related operations (e.g. medical personnel, support staffing, administrative).) � emergency� (Emergency Department operations.) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18. 4.1.22 OperationType Element OperationType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Gathers information about a particular operation type including the kind (taxonomy driven), name (human readable representations), status, and commentary. Comments � Constraints � Sub-elements � name � status � remarks � ext:extension Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18. Element kind Type FacilityOperationKind Usage REQUIRED , MUST be used once and only once Definition The high-level kind of operation that is being reported on (plant, security, staffing, or emergency). Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18. Element name Type FreeTextType Usage REQUIRED , MUST be used once and only once Definition The name of the operation that is being reported on (e.g. "Food Services"). Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18. Element status Type StatusType Usage REQURED , MUST be used once and only once Definition The status of the Operation. Comments � Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type. Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL , MAY be used once and only once Definition General comment/summary on the Operation. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element ext:extension See Section 3.2.4 EDXL Extensions Type Usage OPTIONAL , MAY be used more than once Definition Used to add elements to the OperationType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 14, 16. 4.1.23 ColourCodeDefaultType Element ColourCodeDefaultType Type xs:simpleType (restriction base: edxl-ct:EDXLStringType) Usage REQUIRED , MUST be used once and only once Definition MUST use one of the following � red (RED - severe/extreme deviation from normal condition.� Marks a noted exception from normal conditions.) � yellow (YELLOW - moderate deviation from normal condition but not at SEVERE/EXTREME level.) � green (GREEN - normal conditions.) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. 4.1.24 FacilityKindType Element FacilityKindType Type xs:simpleType (restriction base: edxl-ct:EDXLStringType) Usage REQUIRED , MUST be used once and only once Definition MUST use one of the following � Hospital � longTermCare � urgentCareClinic � temporaryFacility � other Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18. 4.1.25 TraumaCenterLevelKind Element TraumaCenterLevelKind Type xs:simpleType (restriction base: xs:token) Usage REQUIRED , MUST be used once and only once Definition MUST use one of the following � level1 (Level 1 Trauma Services.) � level2 (Level 2 Trauma Services.) � level3 (Level 3 Trauma Services.) � no trauma (Level 4 Trauma Services.) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. 4.1.26 LimitedString Element LimitedString Type xs:simpleType (restriction base: xs:string) Usage OPTIONAL , MUST be used once and only once Definition Text block for preserving whitespace but limiting length to 1024 characters. Comments � Constraints � xs:whitespace = �0� � xs:maxLength = �1024� Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11, 15, 16, 17. 4.1.27 GeoLocationType Element GeoLocationType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Used to provide accurate geospatial information about location. Comments � Constraints � Sub-elements � wgs84Location � geoLocationExtended Requirements �Supported Requirement Numbers 1, 3, 5, 10. Element wgs84Location Type xs:complexType (extension base: edxl-gsf:EDXLGeoLocationType) Usage REQUIRED , MUST be used once and only once Definition The location of the facility in WGS84 coordinates. The values in this element must use the WGS84 (EPSG:4326) values. This element is mandatory to ensure compatibility globally. If alternate SRS are needed, use the geoLocationExtended elements to support 1 or more SRS that are needed in your community. FUTURE versions of HAVE may support additional or alternate globally supported SRS. Comments � srsName attribute is set to a fixed value of http://www.opengis.net/def/crs/EPSG/0/4326 � srsName is the GML Spatial Reference System Name. Constraints Requirements �Supported Requirement Numbers 1, 3, 5, 10. Element geoLocationExtended Type xs:complexType (extension base: edxl-gsf:EDXLGeoLocationType) Usage OPTIONAL , MAY be used more than once Definition The location of the facility in non-WGS84 (EPSG:4326) coordinates. These alternate (and optional) coordinates are intended for the purposes of systems that require the sending system to provide specialize SRS coordinates. Comments � Constraints � attribute srsName is required Requirements �Supported Requirement Numbers 1, 3, 5, 10. 4.1.28 TrafficStatusKind Element TrafficStatusKind Type xs:simpleType (restriction base: xs:token) Usage REQUIRED , MUST be used once and only once Definition MUST use one of the following � normal (Traffic is at levels that are within norms.) � advisory (Traffic levels are high enough to warrant notifying the �that the facility is experiencing higher than expected traffic. � closed (Facility is not accepting patient traffic.) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18. 4.1.29 OffloadInfoType Element OffloadInfoType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Provides information about offload. Comments � Constraints � Sub-elements � offload � ext:extension Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element offload Type OffloadType Usage REQUIRED , MAY be used more than once Definition The particular offload mode, status, and other information for the facility. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element ext:extension See Section 3.2.4 EDXL Extensions Type Usage OPTIONAL , MAY be used more than once Definition Used to add elements to the OffloadInfoType Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 14, 16. 4.1.30 EmergencyDepartmentType Element EmergencyDepartmentType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition The container of all of the elements related to the emergency department status. It describes the ability of this emergency department to treat patients. Comments � Constraints � Sub-elements � status � offloadInfo � traffic � triageCapacity Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11, 13, 14, 17, 18. Element status Type StatusType Usage REQUIRED , MUST be used once and only once Definition Status of the Emergency Department. Comments � Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type. Constraints � Requirements �Supported Requirement Numbers 1, 3, 11, 15, 16, 17, 18. Element offloadInfo Type OffloadInfoType Usage OPTIONAL, MAY be used once and only once Definition Information about the Offload state for various modes of transport (Ambulance, Air Ambulance) Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18 Element traffic Type TrafficType Usage OPTIONAL , MAY be used once and only once Definition Ability of this emergency department to receive patients via emergency medical services. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18. Element triageCapacity Type TriageCapacityType Usage OPTIONAL , MAY be used once and only once Definition The number of each triage patient type the hospital can accept. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. 4.1.31 TriageCapacityType Element TriageCapacityType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition The Count for a particular triage level. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. 4.1.32 TrafficType Element TrafficType Type xs:complexType Usage REQUIRED, MUST be used once and only once Definition Provides context for the TriageCountType Comments � Constraints � Sub-elements � status � colourStatus � reason � remarks Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18. Element status Type TrafficStatusKind Usage REQUIRED , MUST be used once and only once Definition The operating status of the Emergency Department (normal, advisory, closed). Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 11, 15, 16, 17, 18. Element colourStatus Type ColourStatusType Usage REQUIRED, MUST be used once and only once Definition Colour-code status for the Emergency Department. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element reason Type FreeTextType [LimitedString (restriction base: xs:string)] Usage OPTIONAL , MAY be used once and only once Definition The rationale for the colourStatus. It is used to report the contributing factor to an EMSTraffic Status. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 11, 12, 15, 16, 17. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL, MUST be used once and only once Definition General comment/summary on the traffic status. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. 4.1.33 TraumaCenterLevelType Element TraumaCenterLevelType Type xs:complexType Usage REQUIRED , MUST be used once and only once Definition Container for Trauma Center Information. Information provided about the Trauma Center (e.g. Trauma Center Level, status, commentary, etc.) Comments � Constraints � Sub-elements � serviceLevel � status � remarks � ext:extension Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element serviceLevel Type TraumaCenterLevelKind Usage REQUIRED MUST be used once and only once Definition Trauma Center Level - 1 through 3 (I trough III) per American of Surgeons. Beyond Level 3 there is no global standard but this is a good approximation. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element status Type StatusType Usage REQUIRED , MUST be used once and only once Definition The status of the Facility Trauma Center. Comments � Please see the StatusType definition, including sub-element details, for full explanation and guidance on this data type. Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL, MUST be used once and only once Definition General comment/summary on the trauma center status. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. Element ext:extension See Section 3.2.4 EDXL Extensions Type Usage OPTIONAL , MAY be used more than once Definition Used to add elements to the TraumaCenterLevelType. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 14, 16. 4.1.34 ServicesType Element ServicesType Type xs:complexType Usage REQUIRED, MUST be used once and only once Definition Specifies information about a service. Container for a list of Services offered by a Facility. Comments � Constraints � Sub-elements � service � comment Requirements �Supported Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18. Element service Type ServiceType Usage REQUIRED , MAY be used more than once Definition Service provides a description of a particular service - availability, capacity, and status. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL, MAY be used once and only once Definition General comment/summary on all of the services. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. 4.1.35 FutureServicesType Element FutureServicesType Type xs:complexType Usage REQUIRED , MAY be used more than once Definition ServiceListItem provides a description of a particular service - availability, capacity, and status. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18. Element service Type ServiceType Usage OPTIONAL, MUST be used once and only once Definition Service provides a description of a particular service - availability, capacity, and status. Comments � Constraints � Sub-element � reportingPeriod Requirements �Supported Requirement Numbers 1, 3, 5, 11, 15, 16, 17, 18. Element reportingPeriod Type edxl-ct:TimePeriodType Usage REQUIRED , MUST be used once and only once Definition The Reporting Period (interval between a from time and to time) applying to the future Service. Comments � Constraints Must use � fromDateTime � toDateTime Requirements �Supported Requirement Numbers 1, 8. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL, MAY be used once and only once Definition General comment/summary on the all of the future services. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. 4.1.36 OperationsType Element OperationsType Type xs:complexType Usage REQUIRED, MUST be used once and only once Definition Information about operations in a facility. Comments � Constraints � Sub-elements � operation � comment Requirements �Supported Requirement Numbers 1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18. Element operation Type OperationType Usage REQUIRED, MUST used once and only once Definition Operation that facility provides in the context of key areas such as Clinical Operations, Security Operations, Facility Operations. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 3. Element remarks Type edxl-ct:RemarksType Usage OPTIONAL, MAY be used once and only once Definition General comment/summary on all of the operations. Comments � Constraints � Requirements �Supported Requirement Numbers 1, 2, 3, 4, 5, 6, 11, 12, 15, 16, 17, 18, 19. 4.1.37 TraumaCenterType Element TraumaCenterType Type xs:complexType Usage REQUIRED, MUST be used once and only once Definition Trauma Center Level of this facility. The Choice/Sequence approach here allows for at least one of Adult or Pediatric Trauma Center Levels to be provided. Comments � Constraints � Sub-elements � Adult � pediatric Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element adult Type TraumaCenterLevelType Usage REQUIRED, MUST be used once and only once Definition Adult Trauma Services detail. Comments � The Choice/Sequence approach used here allows for at least one of Adult or Pediatric Trauma Center Levels to be provided. Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. Element pediatric Type TraumaCenterLevelType Usage OPTIONAL REQUIRED, MUST MAY be used once and only once Definition General comment/summary on all of the operations. Comments � The Choice/Sequence approach used here allows for at least one of Adult or Pediatric Trauma Center Levels to be provided. Constraints � Requirements �Supported Requirement Numbers 1, 3, 4, 6, 11, 17, 18. 5 Conformance 5.1 Conformance Targets The two following conformance targets are defined in order to support the specification of conformance to this standard: EDXL-HAVE Message; and EDXL-HAVE Message Producer. An EDXL-HAVE Message is an XML 1.0 element whose syntax and semantics are specified in this standard. An EDXL-HAVE Message Producer is a software entity that produces EDXL-HAVE Messages. NOTE� �There is no conformance target corresponding to the consumers of EDXL-HAVE messages 5.2 Conformance as an EDXL-HAVE Message An XML 1.0 element is a conforming EDXL-HAVE-v2.0 Message if and only if: a) it meets the general requirements specified in Section 4; b) if its namespace name is "urn:oasis:names:tc:emergency:edxl:have:2.0", and the element is valid according to the 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 StabilityType Status-comment ST O Status-comment-alttxt ST O Status-comment-altlang ID C N ISO369 comment Use Comment record extension Use Extension record Virtual Table Field Description and Commentary � Operation HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel ST Fixed value: � Operation � Identifies HAVE element represented by this table kind ST name ST name-alttxt ST name-altlang ID 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 comment Use Comment record extension Use Extension record B.2.1.5.5 Virtual Table Field definition � Comment 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 defaultText ST C N alternateText ST C N alternateText-language ID C N ISO369 PID-15.1 Primary Language - identifier Virtual Table Field Description and Commentary � Comment HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel ST Fixed value: � Comment � Identifies HAVE element represented by this table defaultText ST Comment fields not generally mapped to HL7. defaultText must be populated on the first Comment row defaultText should not be populated on subsequent Comment rows alternateText ST Comment fields not generally mapped to HL7. alternateText may be populated on the first Comment row alternateText must be populated on subsequent Comment rows alternateText-language ID alternateText-language must be populated if alternateText is populated B.2.1.5.6 Virtual Table Field definition � Extension 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 Community ST R N ID ST R N Parameter Use Parameter record Virtual Table Field Description and Commentary � Extension HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � Extension � Identifies HAVE element represented by this table Community ST Xsd:anyURI ID ST Xsd:anyURI Parameter Use Parameter record B.2.1.5.7 Virtual Table Field definition � Parameter 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 nameURI ST R N xPath ST O N Value Use Value record Virtual Table Field Description and Commentary � Parameter HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel ST Fixed value: � Parameter � Identifies HAVE element represented by this table nameURI ST Xsd:anyURI xPath ST Value Use Value record B.2.1.5.8 Virtual Table Field definition � Value 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 Value ST R N Uom ST O N Virtual Table Field Description and Commentary � Value HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel ST Fixed value: � Value � Identifies HAVE element represented by this table Value ST Uom ST B.2.1.5.9 Virtual Table Field definition � Service 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 name ST R N name-alttxt ST O N name-altlang ID C N ISO369 Code ST R N 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 StabilityType Status-comment ST O Status-comment-alttxt ST O Status-comment-altlang ID C N ISO369 externalCode EI O Y Entity Identifier ST R N Universal ID ST R N Universal ID Type ID R N 0301 bedCapacity-availableCount NM O N bedCapacity-baselineCount NM O N bedCapacity -comment ST O N bedCapacity -comment-alttxt ST O N bedCapacity -comment-altlang ID C N ISO369 Capacity NM O N CapacityUOM ST O N capacityURI ST O N comment Use Comment record extension Use Extension record Virtual Table Field Description and Commentary � Service HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � Service � Identifies HAVE element represented by this table name ST name-alttxt ST name-altlang ID Code ST Restricted to list ServiceCodeDefaultType 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 externalCode EI Entity Identifier EI.1 ST The value of the external code Universal ID EI.3 ST Xsd:anyURI Universal ID Type EI.4 ID Fixed value: � URI � Identifies exxternalCode.UniversalID as a URI bedCapacity-availableCount NM bedCapacity-baselineCount NM bedCapacity -comment ST bedCapacity -comment-alttxt ST bedCapacity -comment-altlang ID Capacity NM CapacityUOM ST capacityURI ST comment Use Comment record extension Use Extension record B.2.1.5.10 Virtual Table Field definition � FutureService 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 name ST R N name-alttxt ST O N name-altlang ID C N ISO369 Code ST R N 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 StabilityType Status-comment ST O Status-comment-alttxt ST O Status-comment-altlang ID C N ISO369 externalCode EI O Y Ct:value ST R N Ct:valueListURI ST R N Universal ID Type ID R N 0301 bedCapacity-availableCount NM O N bedCapacity-baselineCount NM O N bedCapacity-comment ST O N bedCapacity-comment-alttxt ST O N bedCapacity-comment-altlang ID C N ISO369 Capacity NM O N CapacityUOM ST O N capacityURI ST C N comment Use Comment record extension Use Extension record Virtual Table Field Description and Commentary � Service HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � FutureService � Identifies HAVE element represented by this table name ST name-alttxt ST name-altlang ID Code ST Restricted to list ServiceCodeDefaultType 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 externalCode EI Ct:value EI.1 ST The value of the external code Ct:valueListURI EI.3 ST Xsd:anyURI Universal ID Type EI.4 ID Fixed value: � URI � Identifies exxternalCode.UniversalID as a URI bedCapacity-availableCount NM bedCapacity-baselineCount NM bedCapacity-comment ST bedCapacity-comment-alttxt ST bedCapacity-comment-altlang ID Capacity NM CapacityUOM ST capacityURI ST comment Use Comment record extension Use Extension record B.2.1.5.11 Virtual Table Field definition � Activity 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 reportingPeriod DR O N ��������������� fromDateTime DTM R N ��������������� toDateTime DTM R N Admissions NM R N Discharges NM R N Deaths NM R N comment Use Comment record Virtual Table Field Description and Commentary � Activity HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � Activity � Identifies HAVE element represented by this table reportingPeriod DR ��������������� fromDateTime DTM ��������������� toDateTime DTM Admissions NM Discharges NM Deaths NM comment Use Comment record B.2.1.5.12 Virtual Table Field definition � Resource-Staff 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 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 Needs Use Needs-Offers record Offers Use Needs-Offers record Comment Use Comment record Extension Use Extension record Virtual Table Field Description and Commentary � Resource-Staff HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel � Resource � or � Staff � Identifies HAVE element represented by this table tableLabel ST 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 Needs Use Needs-Offers record Offers Use Needs-Offers record Comment Use Comment record Extension Use Extension record B.2.1.5.13 Virtual Table Field definition � Needs-Offers 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 resourceKind EI O N Ct:value ST R N Ct:valueListURI ST R N Universal ID Type ID R N 0301 Quantity NM R N resourceSize ST R N resourceSizeXpath ST O N Comments Use Comment record Virtual Table Field Description and Commentary � Needs-Offers HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � Needs � or � Offers � Identifies HAVE element represented by this table resourceKind EI Entity Identifier ST The value of the external code Universal ID ST Xsd:anyURI Universal ID Type ID Fixed value: � URI � Identifies exxternalCode.UniversalID as a URI Quantity NM resourceSize ST resourceSizeXpath ST Comments Use Comment record B.2.1.5.14 Virtual Table Field definition � Emergency Department 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 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 offloadInfo Use Offload record Traffic-status ST R N TrafficStatusKind Traffic-status-colourCode ST R N ColourCodeDefaultType Traffic-Status-description ST O N Traffic-Status-description-alttxt ST O N Traffic-Status-description-altlang ID O N ISO369 Traffic-reason ST O N Traffic-reason-alttxt ST O N Traffic-reason-altlang ID C N ISO369 Traffic-comment ST O N Traffic-comment-alttxt ST O N Traffic-comment-altlang ID C N ISO369 triageCapacity Use Triage record Virtual Table Field Description and Commentary � Emergency Department HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel ST Fixed value: � ED � Identifies HAVE element represented by this table 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 offloadInfo Use Offload record Traffic-status ST Traffic-status-colourCode ST N Traffic-Status-description ST N Traffic-Status-description-alttxt ST N Traffic-Status-description-altlang ID N ISO369 Traffic-reason ST Traffic-reason-alttxt ST Traffic-reason-altlang ID N ISO369 Traffic-comment ST Traffic-comment-alttxt ST Traffic-comment-altlang ID triageCapacity Use Triage record B.2.1.5.15 Virtual Table Field definition � Offload 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 OffloadMinutes NM R N 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 Extension Use Extension record Virtual Table Field Description and Commentary � Offload HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description TableLabel Fixed value: � Offload � Identifies HAVE element represented by this table Kind ST OffloadMinutes NM 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 Extension Use Extension record B.2.1.5.16 Virtual Table Field definition � Triage 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 Code ST R N TirageColourCodeType Count NM R N alternateCodeValue ST C N alternateCodeValueURI ST C N comment ST O N comment-alttxt ST O N comment-altlang ID C N ISO369 Virtual Table Field Description and Commentary � Triage HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � Triage � Identifies HAVE element represented by this table Code ST Count NM alternateCodeValue ST alternateCodeValueURI ST comment ST comment-alttxt ST comment-altlang ID B.2.1.5.17 Virtual Table Field definition � Trauma Center 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 serviceLevel ST R N TraumaCenterLevelKind 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 Comment Use Comment record Extension Use Extension record Virtual Table Field Description and Commentary � Trauma Center HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � Adult � or � Pediatric � Identifies HAVE element represented by this table serviceLevel ST 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 Comment Use Comment record Extension Use Extension record B.2.1.5.18 Virtual Table Field definition � GeoLocation Note: GeoLocation representation in HL7 v2.x is limited to the gml:point construct (a point location). 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 Wgs84Location-srsName ST R N Point-ID ST R N Point-srsName ST O N Point-srsDimension NM O N Point-axisLabels ST O Y Point-UOMLaels ST O Y Point-pos NM R Y Point-pos-srsName ST O N Point- pos-srsDimension NM O N Point- pos-axisLabels ST O Y Point- pos-UOMLaels ST O Y Virtual Table Field Description and Commentary � GeoLocation HL7 Column Name (Query ID=Z08) (Uses HAVE element name) HL7 Component Name HL7 Data Type Description tableLabel Fixed value: � GeoLocation � Identifies HAVE element represented by this table Wgs84Location-srsName ST Point-ID ST Point-srsName ST Xsd:anyURI Point-srsDimension NM Xsd:PositiveInteger Point-axisLabels ST Gml:NCName Point-UOMLaels ST gml:NCName Point-pos NM Xsd:double Point-pos-srsName ST Xsd:anyURI Point-pos-srsDimension NM Xsd:PositiveInteger Point-pos-axisLabels ST Gml:NCName Point-pos-UOMLaels ST gml:NCName B.2.1.6 RCP Response Control Parameter Field Description and Commentary Field Seq (Query ID=Z08) Name Com�po�nent Name LEN DT Description Guidance 1 Query Priority 1 ID ( D )eferred or ( I )mmediate.� Default is I . Fixed value = �I� 2 Quantity Limited Request 10 CQ 2.1 Quantity NM Number of units (specified by the following component) that will be returned in each increment of the response.� If no value is given, the entire response will be returned in a single increment. Leave blank (use default value) 2.2 Units CWE CH aracters, LI nes, P a G es, or R ecor D s.� Default is LI . Leave blank (use default value) 3 Response Modality 60 CWE R eal time or B atch.� Default is R . Leave blank (use default value) 7 Segment group inclusion 256 ID What segment group(s) are to be included.� If this field is not valued, all segment groups will be included. Leave blank (use default value) B.2.2 QSX /ACK - cancel subscription/acknowledge message (Event J02) B.2.2.1 QSX^J02^QCN_J01: Cancel Subscription Segments Description Status Sec. Ref MSH Message Header 2.15.9 [{SFT}] Software Segment 2.15.12 [ UAC ] User Authentication Credential 2.14.13 QID Query identification Segment 5.5.3 An existing query subscription can be cancelled by sending a QSX Cancel Subscription message.� The subscription is identified in QID-1 Query Tag and QID-2 Message Query Name.� These values correspond to the QPD-1 and QPD-2 terms in the QSB message which established the subscription.� See example in B.2.3.xx B.2.2.2 ACK^J02^ACK: General Acknowledgment Segments Description Status Sec. Ref MSH Message Header 2.15.9 [{SFT}] Software Segment 2.15.12 [ UAC ] User Authentication Credential 2.14.13 MSA Message Acknowledgment 2.15.8 [ ERR ] Error 2.15.5 This message acknowledges that the subscription has been identified and cancelled.� See example in B.2.3.xx B.2.3 Examples B.2.3.1 Establishing a subscription (From section 2.2.2) 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 ("Community 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. HL7 example message MSH|^~\&|EMS-COMMAND||COMM-HOSP||201803110800-0800|| QSB^Z08^QSB_Q16|112233|P|2.8| QPD|Z08^HAVE 2.0 Subscription^HL70471|IN20180311-0012| RCP|I||||N| HL7 example message content MSH.3 EMS-COMMAND Identifies sending application, i.e., the EMS command & control system MSH.5 COMM-HOSP Identifies receiving application, i.e., "Community Hospital" MSH.7 201803110830-0800 Date and time of message, i.e., March 11, 2018 @ 8:30 AM PST MSH.9 QSB^Z08^QSB_Q16 Identifies the message type and trigger, i.e., creating HAVE subscription MSH.10 112233 System generated message identifier MSH.11 P Production message MSH.12 2.8 HL7 v2.8 QPD.1 Z08^HAVE 2.0 Subscription^HL70471 Identifies the subscription query, i.e., HAVE 2.0 report QPD.2 IN20180311-0012 Subscription identifier, sent back with responses to link responses to query request RCP.1 I Immediate Response (e.g., start subscription now) RCP.5 N New subscription request B.2.3.2 HAVE report in response to a subscription "Community Hospital" responds to the subscription establish by the Incident Commander.� This response would be repeated, with updated information, based upon pre-established schedule. HL7 example message MSH|^~\&|COMM-HOSP||EMS-COMMAND||201803110845-0800|| RTB^Z09^RTB_Z09|ad4v5s|P|2.8| MSA|AA|112233| QAK|IN20180311-0012|OK|Z08^HAVE 2.0 Subscription^HL70471| QPD|Z08^HAVE 2.0 Subscription^HL70471|IN20180311-0012| RDF|3|tableLabel^ST~defaultLanguage^ID~reportingPeriod^DR| RDT|HAVE|en| RDF|21|tableLabel^ST~ OrganisationName^XON~ Addresses^XAD~ Address-Locality-SubLocality-NameElement^ST~ ContactNumbers^XTN~ ContactNumber-ContactHours^ST~ ElectronicAddressIdentifiers^XTN~ OrganizationInfo-Type^ST~ OrganizationInfo-CategoryType^ST~ OrganizationInfo-Status^ST~ OrganizationInfo-Nature^ST~ OrganizationInfo-IndustryType^ST~ OrganizationInfo-IndustryCode^ST~ OrganizationInfo-IndustryCodeType^ST~ OrganizationInfo-NumberOfEmployees^ST~ OrganizationInfo-OperatingHourStartTime^TM~ OrganizationInfo-OperatingHourStartTime^DTM~ OrganizationInfo-DataQualityType^ST~ OrganizationInfo-ValidFrom^DT~ OrganizationInfo-ValidTo^DT~ OrganizationInfo-##other^ST| RDT|OrganisationInformation|Community Hospital^^^^^^XX^^^COMM-HOSP|1 Hospital Way^^Anytown^CA^95999^US^^^&Midland County|| �<additional organization information> RDF|21|tableLabel^ST~ ID^ST~ parentID^ST~ name^ST~ name-alttxt^ST~ name-altlang^ID~ kind^ST~ reportingPeriod^DR~ lastUpdate^DTM~ status-isOK^ID~ 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~ Operations-comment^ST~ Operations-comment-alttxt^ST~ Operations-comment-altlang^ID RDT|Facility|||Community Hospital|||Hospital|� RDF|21|tableLabel^ST~ OrganisationName^XON~ Addresses^XAD~ Address-Locality-SubLocality-NameElement^ST~ ContactNumbers^XTN~ ContactNumber-ContactHours^ST~ ElectronicAddressIdentifiers^XTN~ OrganizationInfo-Type^ST~ OrganizationInfo-CategoryType^ST~ OrganizationInfo-Status^ST~ OrganizationInfo-Nature^ST~ OrganizationInfo-IndustryType^ST~ OrganizationInfo-IndustryCode^ST~ OrganizationInfo-IndustryCodeType^ST~ OrganizationInfo-NumberOfEmployees^ST~ OrganizationInfo-OperatingHourStartTime^TM~ OrganizationInfo-OperatingHourStartTime^DTM~ OrganizationInfo-DataQualityType^ST~ OrganizationInfo-ValidFrom^DT~ OrganizationInfo-ValidTo^DT~ OrganizationInfo-##other^ST| RDT|OrganisationInformation|Community Hospital^^^^^^XX^^^COMM-HOSP|1 Hospital Way^^Anytown^CA^95999^US^^^&Midland County|| � RDF|12|tableLabel^ST~ Wgs84Location-srsName^ST~ Point-ID^ST~ Point-srsName^ST~ Point-srsDimension^NM~ Point-axisLabels^ST~ Point-UOMLaels^ST~ Point-pos^NM~ Point-pos-srsName^ST~ Point-pos-srsDimension^NM~ Point-pos-axisLabels^ST~ Point-pos-UOMLaels^ST| RDT|GeoLocation||||||||36.578871 -121.913183| RDF|23|tableLabel^~ name^ST~ name-alttxt^ST~ name-altlang^ID~ Code^ST~ status-isOK^ID~ 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~ externalCode^EI~ bedCapacity-availableCount^NM~ bedCapacity-baselineCount^NM~ bedCapacity -comment^ST~ bedCapacity -comment-alttxt^ST~ bedCapacity -comment-altlang^ID~ Capacity^NM~ CapacityUOM^ST~ capacityURI^ST| RDT|Service|Community Hospital Burn Unit|||burnUnit|Y|yellow||Stable|||||2|5| HL7 example message content MSH.3 COMM-HOSP Identifies sending application, i.e., "Community Hospital" MSH.5 EMS-COMMAND Identifies receiving application, i.e., the EMS command & control system MSH.7 201803110845-0800 Date and time of message, i.e., March 11, 2018 @ 08:45 AM UTC-8hr (PST) MSH.9 RTB^Z09^RTB_Z09 Identifies the message type and trigger, i.e., a HAVE subscription response MSH.10 ad4v5s System generated message identifier MSH.11 P Production message MSH.12 2.8 HL7 v2.8 MSA.1 AA Affirmative Acknowledgement code MSA.2 112233 Identifier from initial message (i.e., the subscription request message) QAK.1 IN20180311-0012 Subscription identifier specified in the initial request QAK.2 OK Query status, "OK"="data found, no errors" QAK.3 Z08^HAVE 2.0 Subscription^HL70471 Identifies the subscription query, i.e., HAVE 2.0 report QPD Segment repeated from initial request RDF/RDT where RDT.1="HAVE" This corresponds to the HAVE root segment information RDT.1 HAVE This is a HAVE record RDF/RDT where RDT.1="OrganizationInformation" Organization information for the sender of the HAVE message.� Required to follow HAVE RDT.2.1 Community Hospital Organization name of the HAVE sender RDT.2.7 XX Type of identifier. ("XX"=non-specific organization ID") RDT.2.10 COMM-HOSP Organization identifier RDT.3 1 Hospital Way^^Anytown^CA^ 95999^US^^^&Midland County Organization address: 1 Hospital Way Anytown, CA 95999 Midland County USA � Additional Organization information could be provided but is not essential in this example RDF/RDT where RDT.1="Facility" Facility information within the Organization.� There must be at least one Facility per Organization. RDT.4 Community Hospital Name of facility RDT.7 Hospital Coded type of facility � Additional Facility information could be provided but is not essential in this example RDF/RDT where RDT.1=" OrganizationInformation " Organization information specific to the preceding Facility.� Required to follow Facility (may differ from Organization information associated with HAVE sender. The organization information from the HAVE segment is repeated here.� In this example, the facility and HAVE sender have the same organization information RDF/RDT where RDT.1="GeoLocation" GeoLocation information for the Facility.� RDT.8 36.578871 -121.913183 GeoLocation coordinates (lat/lon) for the facility RDF/RDT where RDT.1="Service" RDT.2 Community Hospital Burn Unit Human-readable name of Service RDT.5 burnUnit Coded service type RDT.6 Y "isOK" indicator for service RDT.7 yellow Red/Yellow/Green status of service RDT.9 Stable Service status indicator RDT.14 2 Available beds RDT.15 5 Baseline beds(capacity) B.2.3.3 Cancel a subscription The multi-unit residential fire incident has been resolved and closed.� The HAVE information feed is no longer needed. HL7 example message MSH|^~\&|EMS-COMMAND||COMM-HOSP||201803120000-0800|| QSX^J99^QSX_J01|10211211|P|2.8| QID|IN20180311-0012|Z08^HAVE 2.0 Subscription^HL70471| HL7 example message content MSH.3 EMS-COMMAND Identifies sending application, i.e., the EMS command & control system MSH.5 COMM-HOSP Identifies receiving application, i.e., "Community Hospital" MSH.7 201803120000-0800 Date and time of message, i.e., March 12, 2018 @ 00:00 AM UTC-8hr (PST) MSH.9 QSB^Z08^QSB_Q16 Identifies the message type and trigger, i.e., creating HAVE subscription MSH.10 10211211 System generated message identifier MSH.11 P Production message MSH.12 2.8 HL7 v2.8 QID.1 IN20180311-0012 Subscription identifier from initial subscription, link cancellation to query request QID.2 Z08^HAVE 2.0 Subscription^HL70471 Identifies the subscription query, i.e., HAVE 2.0 report Appendix C. Revision History Revision Date Editor Changes Made WD02 23DEC2014 Darrell O�Donnell Preparation for submission to OASIS EM-TC WD02 13JAN2015 Darrell O�Donnell Updates to reflect information models in the CT, CIQ, and GSFworking drafts. CSD01 13JAN2015 Darrell O�Donnell Updates to reflect EM TC Committee Specification Draft WD03 22AUG2017 Rex Brooks Changes pursuant to new Committee Specification Public Review Draft WD04 11NOV2017 Darrell O�Donnell Changes for Appendix B: HL7 after receipt from Scott Robertson�s heroic effort WG04 05FEB2018 Scott M. Robertson Changes pursuant to HL7 ballot comments

Related documents

• XLIFF v2.0 (2014-08-06)#601010
• XLIFF Version 2.2 (2025-03-13)#601012
• XACML v3.0 Separation of Duties Version 1.0 (2024-01-30)#601007
• XACML v3.0 Time Extensions Version 1.0 (2020-02-14)#601008
• XLIFF v2.1 (2018-02-14)#601011