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:
HL7 Patient Administration Work Group
Chair:
Elysa Jones (elysajones@yahoo.com), Individual
Editors:
Darrell O’Donnell (darrell.odonnell@continuumloop.com), Individual
Brian Wilkins (bwilkins@mitre.org), MITRE Corporation
Rex Brooks (rexb@starbourne.com), individual
Scott M. Robertson (scott.m.robertson@kp.org), Kaiser Permanente
This specification replaces or supersedes:
This specification is related to:
Declared XML namespace:
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 |
SNOMED CT |
SNOMED International http://www.snomed.org/snomed-ct/get-snomed-ct or info@ihtsdo.org |
Logical Observation Identifiers Names & Codes (LOINC) |
Regenstrief Institute |
International Classification of Diseases (ICD) codes |
World Health Organization (WHO) |
NUCC Health Care Provider Taxonomy code set |
American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services) |
HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off. Please see http://www.hl7.org/legal/trademarks.cfm for additional guidance on Health Level Seven-owned trademarks.
Table of Contents
1.6 Structure of the EDXL Hospital Availability Exchange Specification
2 Design Principles & Concepts (non-normative)
2.2.1 Day-to-Day – Dialysis Patient:
2.2.2 First Responder – Responding with Critical Care
2.2.3 Mass-Scale Vaccination Clinics
3.1 HAVE Report Definition (non-normative)
3.2 Supporting Elements (non-normative)
3.2.2 Selecting Values from Lists
3.3 Element Reference Model (non-normative)
3.4 Distribution of EDXL-HAVE (non-normative)
4.1.6 OffloadStateKind Element
4.1.8 OrganizationInformationType
4.1.11 ResourceInformationType
4.1.21 FacilityOperationKind Element
4.1.30 EmergencyDepartmentType
5.2 Conformance as an EDXL-HAVE Message
5.3 Conformance as an EDXL-HAVE Message Producer
Appendix B. HL7 Implementation Guidance
B.2.1 HL7 Query Conformance Statement
B.2.1.2 Query Grammar: QSB Message (QSB^Z08^QSB_Q16)
B.2.1.3 Response Grammar: RTB Message (RTB^Z09^RTB_Z09)
B.2.1.4 QPD Input Parameter Specification
B.2.1.5 Input/Output Specification: Virtual Table
B.2.1.5.1 Virtual Table Field definition – HAVE record
B.2.1.5.2 Virtual Table Field definition – OrganisationInformation
B.2.1.5.3 Virtual Table Field definition – Facility
B.2.1.5.4 Virtual Table Field definition – Operation
B.2.1.5.5 Virtual Table Field definition – Comment
B.2.1.5.6 Virtual Table Field definition – Extension
B.2.1.5.7 Virtual Table Field definition – Parameter
B.2.1.5.8 Virtual Table Field definition – Value
B.2.1.5.9 Virtual Table Field definition – Service
B.2.1.5.10 Virtual Table Field definition – FutureService
B.2.1.5.11 Virtual Table Field definition – Activity
B.2.1.5.12 Virtual Table Field definition – Resource-Staff
B.2.1.5.13 Virtual Table Field definition – Needs-Offers
B.2.1.5.14 Virtual Table Field definition – Emergency Department
B.2.1.5.15 Virtual Table Field definition – Offload
B.2.1.5.16 Virtual Table Field definition – Triage
B.2.1.5.17 Virtual Table Field definition – Trauma Center
B.2.1.5.18 Virtual Table Field definition – GeoLocation
B.2.1.6 RCP Response Control Parameter Field Description and Commentary
B.2.2 QSX /ACK - cancel subscription/acknowledge message (Event J02)
B.2.2.1 QSX^J02^QCN_J01: Cancel Subscription
B.2.2.2 ACK^J02^ACK: General Acknowledgment
B.2.3.1 Establishing a subscription
B.2.3.2 HAVE report in response to a subscription
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]
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).
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].
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.
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
The ongoing goal of the Emergency Data eXchange Language (EDXL) project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national, international and non-governmental organizations of different professions that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved.
The current roster of published EDXL Standards includes:
The primary purpose of EDXL-HAVE is to provide an XML-based reporting format that allows information to be shared about a set of health facilities including the communication of the status of a health facility, its services, and its resources. These include bed capacity and availability, emergency department status, staffing levels, available service coverage, and the status of a health facilities operations and resources.
The primary audience for EDXL-HAVE is the broad community that interacts with health facilities and it is intended to be used as a tool to automate information flow in and out of the health network. It is not intended to be a tool used for internal administration of health facilities as other standards organizations (e.g. Health System Level Seven International – www.hl7.org) already handle this domain.
In a disaster or emergency situation, there is a need for hospitals to be able to communicate with each other, and with other members of the emergency response community. The ability to exchange data in regard to hospitals’ bed availability, status, services, and capacity enables both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiency and speed. In particular, it will allow emergency dispatchers and managers to make sound logistics decisions such as where to route victims and automatically determining which hospitals have the ability to provide the needed service. Many hospitals have expressed the need for, and indeed are currently using, commercial or self-developed information technology that allows them to publish this information to other hospitals in a region, as well as Emergency Operations Centers (EOCs), 9-1-1 centers, and Emergency Medical Systems (EMS) responders via a Web-based tool.
The Hospital Availability Exchange standard was created to make sharing information about the state of hospitals for day-to-day and crisis use. Initially it was focused purely on hospitals but it has been extended to handle sharing information about the broader health network, including long-term care facilities, urgent care clinics, and temporary aid centers.
HAVE 1.0 was released on 22DEC2009. Since the release of HAVE 1.0 there have been multiple operational uses of HAVE, including after the 2010 Haiti Earthquake. In many of the operational uses there were modified schema used to add services that were not in HAVE 1.0 and to convey other aspects of the data and to handle the sharing of information about non-hospital facilities (e.g. clinics, temporary locations). The use of the HAVE 1.0 standard was encouraging but the shortfalls needed to be addressed. To that end, in 2010 the OASIS EM-TC voted to re-open the HAVE standard with the goal of creating a HAVE 2.0 standard.
The HAVE data exchange standard goes hand in hand with the EDXL Tracking of Emergency Patients (TEP). A TEP-based data exchange collects data on patients from incident EMS first encounter and field hospital triage to EMS transport and patient registration at a definitive care facility such as a hospital emergency room. It can also be used for the routine transport of patients and for the evacuation of hospitals involving EMS transport and care. In all scenarios, it relieves the heavy administrative burden levied on staff to re-key patient information, often after the fact, enabling automatic and pro-active hospital preparedness. In September of 2016, a bidirectional transformation specification between TEP and HL7 messaging was completed. This enables the transformation of the TEP data taken by emergency response to automatically populate in hospital data systems.
HAVE supports the TEP standard by providing the data needed about available hospital resources to enable the informed routing decisions needed by EMS. In this way, the patients can be routed to the hospital with the facilities needed to support their needs. Given the TEP, the emergency room will be able to see the data about the incoming patient in order to best prepare for their optimal care. Both of these initiatives began with the Department of Homeland Security Science and Technology (DHS S&T) effort to identify the next most important data standards needed for emergency response. Practitioners in both the medical and emergency management domains were included in developing draft specifications after many facilitated sessions to include scenario working groups.
The National Association of Emergency Medical Services Officials (NASEMSO) is one organization that participated in the DHS S&T effort. In October 2015, NASEMSO issued a resolution to encourage the completion and implementation of the TEP and HAVE standards.
The DHS S&T effort concluded with two live exercises utilizing both TEP and HAVE (see next section).
The HAVE 2.0 will be coordinated with HL7 through the work of the Patient Administration Work Group. OASIS and HL7 intend to release a joint specification for the HAVE Standard under the Statement of Understanding between the organizations. The effective exchange and common data interoperability will enable both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiently and speed.
The TEP and HAVE Standards Have Been Proven Successful in Live Exercises
The draft TEP standard was successfully implemented by four independent systems: Tennessee’s state EMS system and a local EMS system in Memphis, the state of Maryland EMS system, and the federal JPATS system. The Integrated Public Alerts and Warnings System (IPAWS) was plugged in as the message broker (the “post office” that routes data traffic where users need). State, local and federal agencies proved that these standards-based data exchanged work by plugging into existing major live-actor patient movement exercises at disaster sites, aircraft bases and hospitals.
At the 2012 Integrated Medical, Public Health, Preparedness and Response Training Summit, presenters from the DHS S&T Practitioner Steering Group moved volunteer patients through the room to different “states” and were able to display data updates across four independent systems including JPATS.
In these exercises and the 2012 demonstration, as each existing system automatically scanned, entered or updated patient data, that data was automatically shared in near real-time behind the scenes with no manual intervention, allowing users to view and report data in their own systems as if all data updates were made there. Using an aggregation of multiple hospital HAVE reports, emergency managers were able to route patients to appropriate destinations.
The EDXL-HAVE 2.0 standard document structure is defined using successively more detailed or constrained artifacts in the form of textual descriptions, diagrams, figures, tables and Appendices. The EDXL-HAVE XML Schema is provided separately. The overall structure of the EDXL-HAVE report is first represented in an Element Reference Model (ERM). The ERM is the foundation from which individual constraint schemas (individual situation report types) are defined.
The structure of the EDXL-HAVE standard is defined in the following sections:
These sections together define the message structure, message element definitions, optionality and
cardinality.
Below are some of the guiding principles behind the development of EDXL-HAVE:
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
The following scenarios illustrate how EDXL-HAVE 2.0 can be used in the field.
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.
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.
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.
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.)
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.
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:
Supporting Element Types borrow re-usable elements from the EDXL Common Types (ct:) that apply to and support multiple areas of the HAVE 2.0 reports, such as Location. For instance incidentLocation relies on ct:EDXLLocationType, which consists of either EDXLGeoLocation for geographical information or EDXLGeoPoliticalLocation for geopolitical information. EDXLGeoLocation is of type edxl-gsf:EDXLGeoLocationType and EDXLGeoPoliticalLocation is of type ct:EDXLGeoPoliticalLocationType. This latter type consists of either a GeoCode (of type ct:ValueListType) or an Address (of type edxl-ciq:xAL:AddressType).
The following elements are used in this specification and can be found at the locations cited in the normative references in Section 1.2 of this document.
Supporting Element/Type |
Defined In |
ct:EDXLDateTimeType |
EDXL-CT (Simple Types) |
ct:EDXLStringType |
EDXL-CT (Simple Types) |
ct:ValueListURIType |
EDXL-CT (Simple Types) |
ct:ValueType |
EDXL-CT (Simple Types) |
ct:ValueListType |
EDXL-CT (Complex Types) |
ct:ValueKeyType |
EDXL-CT (Complex Types) |
ct:EDXLGeoPoliticalLocationType |
EDXL-CT (Complex Types) |
ct:EDXLLocationType |
EDXL-CT (Complex Types) |
gsf:EDXLGeoLocationType |
EDXL-GSF |
ct:ValueListURI |
EDXL-CT (Top Level Elements) |
xal:addressType |
EDXL-CIQ |
|
|
Some elements of the common type “ct:EDXLStringType” are denoted as [token] in the accompanying XML per the following reference:
[token] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#token, W3C REC-xmlschema-2, October 2004.
The definition for token as found in the OASIS common types is: “The value space of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces.”
The implication is that the XML parser will change string entries to remove carriage returns, line feeds, tab characters, leading or trailing spaces, and internal sequences of two or more spaces.
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
The schema for ValueKeyType is defined as
<xs:complexType name="ValueKeyType">
<xs:sequence>
<xs:element ref="ct:ValueListURI" minOccurs="1" maxOccurs="1"/>
<xs:element ref="ct:Value" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
and its application to the XML description of an element elementName of type ct:ValueKeyType would be:
<elementName>
<ct:ValueListURI>valueListURI</ct:ValueListURI>
<ct:Value>value</ct:Value>
</elementName>
This example uses a published list of values and definitions and selects one specific entry to describe a resource need of a facility:
which stands for
<resourceKind>
<ct:ValueListURI>https://www.medwish.org/give/medical-supplies/</ct:ValueListURI>
<ct:Value>Bandages</ct:Value>
</resourceKind>
Following the approach in ValueList, we'd point ValueListURI to some other list to make a different selection of eye colors available.
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:
In HAVE 2.0, “Extensions” are used under the following elements:
The schema for Extension is defined as
<xs:element name="extension">
<xs:complexType>
<xs:sequence>
<xs:element name="community" type="xs:anyURI" />
<xs:element name="id" type="xs:anyURI /">
<xs:element name="parameter" type="ext:ParameterType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
and its application to the XML description of an extension would be:
<extension>
<community>communityURI</community>
<id>idURI</id>
<parameter>
<nameURI>nameURI</nameURI>
<value>some value</value>
</parameter>
</extension>
This example uses a qualify for status stability for a service:
which stands for
<extension>
<community>facility:service:status:refined</community>
<id>extension:1</id>
<parameter>
<nameURI>have:service:status</nameURI>
<value>Rapidly</value>
</parameter>
</extension>
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.
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).
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.
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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.
|
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. |
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. |
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
|
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
The two following conformance targets are defined in order to support the specification of conformance to this standard:
An EDXL-HAVE Message is an XML 1.0 element whose syntax and semantics are specified in this standard. An EDXL-HAVE Message Producer is a software entity that produces EDXL-HAVE Messages.
NOTE There is no conformance target corresponding to the consumers of EDXL-HAVE messages
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”.
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.
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.
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.
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.
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.
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)
Description |
|
Sec. Ref |
|
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/ |
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 |
|
|
|
|
|
|
|
Use Organization record |
|
DR |
O |
N |
|
|
|
|
fromDateTime |
|
DTM |
R |
N |
|
|
|
toDateTime |
|
DTM |
R |
N |
|
|
|
|
|
|
|
|
|
|
Use Facility record |
|
|
|
|
|
|
|
Use Comment record |
|
|
|
|
|
|
|
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. |
|
|
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 |
|
|
|
Use Facility record |
|
|
|
Use Comment record |
|
|
|
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 |
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 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 |
|
|
|
|
|
|
|
|
|
|
Organization record |
|
|
|
|
|
|
|
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 record |
|
|
|
|
|
|
|
FutureServices record |
|
|
|
|
|
|
|
Activity record |
|
|
|
|
|
|
|
Operation record |
Operations-comment |
|
ST |
O |
N |
|
|
|
Operations-comment-alttxt |
|
ST |
O |
N |
|
|
|
Operations-comment-altlang |
|
ID |
O |
N |
ISO369 |
|
|
|
|
|
|
|
|
|
Resource-Staff record |
|
|
|
|
|
|
|
Resource-Staff record |
|
|
|
|
|
|
|
ED record |
|
|
|
|
|
|
|
TraumaCenter record |
|
|
|
|
|
|
|
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 |
|
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 |
|
|
|
|
Organization record |
|
|
|
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 record |
|
|
|
FutureServices record |
|
|
|
Activity record |
|
|
|
Operation record |
Operations-comment |
|
ST |
|
Operations-comment-alttxt |
|
ST |
|
Operations-comment-altlang |
|
ID |
|
|
|
|
Resource-Staff record |
|
|
|
Resource-Staff record |
|
|
|
Emergency Department record |
|
|
|
Trauma Center record |
|
|
|
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 |
|
|
|
|
|
|
|
|
|
Use Comment record |
|
|
|
|
|
|
|
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 |
|
|
|
|
Use Comment record |
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
Use Comment record |
|
|
|
|
|
|
|
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 |
|
|
|
|
Use Comment record |
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
Use Comment record |
|
|
|
|
|
|
|
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 |
|
|
|
|
Use Comment record |
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
||
|
|
|
|
|
|
|
Use Needs-Offers record |
||
|
|
|
|
|
|
|
Use Needs-Offers record |
||
|
|
|
|
|
|
|
Use Comment record |
||
|
|
|
|
|
|
|
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 |
|
|
|
|
Use Needs-Offers record |
|
|
|
Use Needs-Offers record |
|
|
|
Use Comment record |
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
Use Comment record |
|
|
|
|
|
|
|
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 |
|
|
|
|
Use Comment record |
|
|
|
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 |
Component 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 |
CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
Leave blank (use default value) |
3 |
Response Modality |
|
60 |
CWE |
Real time or Batch. 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 |
|
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.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 |
|
… |
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) |
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 |
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 |