Bi-directional Transformation of OASIS EDXL-TEP (Tracking of Emergency Patients) v1.1 and HL7 v2.7.1 Specification Version 1.0

Committee Note 01

31 May 2016

Specification URIs

This version:

http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/cn01/TEP-HL7v2-transforms-v1.0-cn01.docx (Authoritative)

http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/cn01/TEP-HL7v2-transforms-v1.0-cn01.html

http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/cn01/TEP-HL7v2-transforms-v1.0-cn01.pdf

Previous version:

N/A

Latest version:

http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/TEP-HL7v2-transforms-v1.0.docx (Authoritative)

http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/TEP-HL7v2-transforms-v1.0.html

http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/TEP-HL7v2-transforms-v1.0.pdf

Technical Committee:

OASIS Emergency Management TC

Chair:

Elysa Jones (elysajones@yahoo.com), Individual

Editors:

Patti Aymond (patti.aymond@iem.com), IEM, Inc.

Lizzie DeYoung (edeyoung@mitre.org), The MITRE Corporation

Timothy Grapes (tgrapes@hotmail.com), Individual

Werner Joerg (wjoerg@computer.org), Individual

John Roberts (John.A.Roberts@tn.gov), Tennessee Department of Health

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

Additional artifacts:

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

·         TEPv1.1-HL7v2.7.1-Transforms:
http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/cn01/TEPv1.1-HL7v2.7.1-Transforms-v1.0.xls

Related work:

This document is related to:

·         HL7 V2.7.1: http://www.hl7.org/documentcenter/private/standards/v271/V271_FinalStandard_Word_and_PDF.zip

o   HL7 Patient Administration (ADT) message (Chapter 3)

o   HL7 Pharmacy/Treatment Administration (RAS) message (Chapter 4a) related documents

·         OASIS Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Version 1.1. Latest version: http://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.html

·         Emergency Data Exchange Language (EDXL) Distribution Element, v1.0. OASIS Standard. http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf

·         Emergency Data Exchange Language (EDXL) Distribution Element Version 2.0. Latest version. http://docs.oasis-open.org/emergency/edxl-de/v2.0/edxl-de-v2.0.html

Abstract:

This document provides context in the use of the " TEPv1.1-HL7v2.7.1-Transforms-v1.0.xls " Spreadsheet.  This document in conjunction with the referenced .xls file provides a guide for accurate mapping and transforms between the OASIS EDXL-TEP (Emergency Data Exchange Language - Tracking of Emergency Patients) v1.1 standard used in the emergency services setting, and the HL7 V2.7.1 ADT / RAS messages used in the healthcare setting. 

OASIS EDXL-TEP is an OASIS Emergency Management Technical Committee (EM-TC) international public standard that enables emergency patient tracking data exchange between the myriad of systems used by Emergency Management (EM) and Emergency Medical Services (EMS).  Patient movement, condition, and care are tracked and shared throughout the emergency continuum of care, from initial encounter with emergency services to the point of admittance to a healthcare facility.

HL7 V2.7.1 ADT (Admit, Discharge and Transfer) message is an international public standard that enables hospital patient tracking data exchange between the various hospital systems involved in patient admission, transfer and discharge.

HL7 V2.7.1 RAS (Pharmacy/Treatment Administration) message is may be created by the administering application (e.g., nursing application) for each instance of administration for an existing pharmacy or treatment order.

The purpose of this effort is to:

·         Improve and speed and content of communication between the emergency response community and hospitals, and between hospitals in a disaster situation

·         Increase ER preparation for incoming emergency patients

·         Improve continuity of patient care

·         Enhance the Common Operating Picture (COP)

·         Facilitate collaboration and coordination

·         Assist data exchange implementation

This specification provides a mechanism for hospitals/EDs to track incoming patients from emergency services in the field via existing HL7 conformant systems.  It also includes the specification for transforming an HL7 V2.7.1 message to an EDXL-TEP message if a patient must be transported from the healthcare facility by emergency services to another healthcare facility (e.g. Hospital Evacuation).

This transformation specification provides an ontological matching between EDXL-TEP v1.1 and HL7 V2.7.1 ADT/RAS messages, including concepts, vocabulary, type conversions, and transformation rules.  It is used to produce bidirectional data transforms between EDXL-TEP and HL7 messages useful in both normal operations and in emergency situations.

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.

Technical Committee (TC) members should send comments on this document 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/.

Citation format:

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

[TEP-HL7-transform]

Bi-directional Transformation of OASIS EDXL-TEP (Tracking of Emergency Patients) v1.1 and HL7 v2.7.1 Specification Version 1.0. Edited by Patti Aymond, Lizzie DeYoung, Timothy Grapes, Werner Joerg, John Roberts, and Brian Wilkins. 31 May 2016. OASIS Committee Note 01. http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/cn01/TEP-HL7v2-transforms-v1.0-cn01.html. Latest version: http://docs.oasis-open.org/emergency/TEP-HL7v2-transforms/v1.0/TEP-HL7v2-transforms-v1.0.html.

 

Copyright © OASIS Open 2016.  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.

 

Copyright © Health Level Seven International 2016.  All Rights Reserved.

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.

If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material.

-          A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.

-          INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

-          B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.

-          C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part.

-          NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.

See http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

 

1       Introduction. 1

1.1         The Transform Discovery Process. 1

1.2         Structure and usage of this document 2

1.3         References. 2

2       Scope – Scenarios and Use Cases. 4

2.1 Hospital-to-Hospital transfer. 4

2.2 Incoming Patients. 5

2.3 Hospital Transfers. 5

2.4 Regional Coordination. 6

2.5 Federal Support 7

3       Background. 8

3.1 OASIS EDXL-TEP. 8

3.1.1 The EDXL Family of Emergency Management Messaging Standards. 8

3.1.2 EDXL-TEP Development 8

3.1.3 Current status. 8

3.2 HL7 V2.7.1 Healthcare Messaging Standard. 9

3.2.1 The HL7 messaging Standard. 9

3.2.2 Current Status. 9

4       Transforms Spreadsheet 10

4.1 Spreadsheet Tabs Summary. 10

4.2 Transform Tabs. 12

4.2.1 EDXL-TEP message details. 12

4.2.2 The ADT message details. 13

4.2.3 5.1.3 Transformations. 14

5       EDXL data structures. 15

5.1 EDXL Elements. 15

5.1.1 Atomic Elements. 15

5.1.2 Complex Elements. 15

5.1.3 A note about lists. 16

5.1.4 A note about Extensions. 16

5.2 EDXL-TEP. 19

5.2.1 EDXL-TEP message structure. 19

5.2.2 Auxiliary EDXL-TEP message structures. 21

5.2.3 Auxiliary shared EDXL structures. 22

5.3 EDXL-DE. 23

6       HL7 Data Structures. 27

6.1 ADT/A14 – Pending Admit 27

1.4         ADT/A03 – Discharge/End Visit 46

1.5         RAS/017 – Pharmacy/Treatment Administration. 64

Appendix A.       Unmapped EDXL-TEP Elements. 81

Appendix B.        Acknowledgments. 82

Appendix C.        Revision History. 85

 

 

EDXL-TEP, the Tracking of Emergency Patients, is a messaging standard that facilitates the coordination of patient movement across the continuum of emergency medical care. The care continuum includes day-to-day EMS transfer and regional transport coordination; it includes regional mass casualty event response, and it includes large-scale, ESF-8 supported hospital evacuation efforts. EDXL-TEP supports cross-jurisdiction, cross-profession, and cross-technology information sharing.

Hospitals use the HL7 Messaging Standard internally and in information exchange with other healthcare facilities, including other hospitals. The EDXL-TEP/HL7 transform is provided to bridge the electronic gap between the Emergency Management and EMS communities and the hospital community.

This document is the result of a collaborative process by the OASIS Emergency Management Technical Committee (EM-TC), and HL7 Public Health and Emergency Response (PHER), Emergency Care (EC), Clinical Interoperability Council (CIC), Patient Care (PC) and Patient Administration (PA) Work Groups, with other HL7 subject matter expert (SME) input during the mapping process.

This specification will allow software systems to produce bidirectional data transforms between EDXL-TEP 1.1 and HL7 2.71 messages useful in both normal operations and in emergency situations. 

As defined in the collaboration agreement, a formal objective of the transform involves EDXL-TEP information exchange with hospitals prior to patient arrival, thus increasing preparation time and ensuring continuity of continued patient care. Conversely, information exchange with Emergency Management transportation services (e.g., ambulance services) prior to patient pick-up at the hospital will increase preparation time and ensuring continuity of continued patient care.

1.1      The Transform Discovery Process

To minimize the number of transform rules, the discovery of transforms has been governed by the following process (target and originating data structures are determined by the intended transform direction TEP <-> ADT/TEP -> RAS):

1.       Identify all Required elements in target data structure

a.       For every required element search for matching structure(s) in originating data structure

b.      If matching structure found, generate transform rule(s); if not, provide transform strategy

2.       Identify all Optional/Conditional elements in target data structure

a.       For every optional/conditional element search for matching structure(s) in originating data structure

b.      If matching structure found, generate transform rule(s); if not, drop the element from transform set

3.       Identify all interesting [1]elements in originating data structure

a.       For every such interesting element, search corresponding structure in target data structure

b.      If corresponding structure found, generate transform rule(s)

c.       If no corresponding structure found, consider options to add extension(s)

                                                               i.      If option(s) exist, generate transform rules

                                                             ii.      If not, drop item.

1.2      Structure and usage of this document

This document briefly addresses the use cases and scope of the standard, and then guides the reader in the use of the accompanying spreadsheet (TEPv1.1-HL7v2.7.1-Transforms-v1.0.xls) that details the mapping and processing to transform an OASIS/EDXL-TEP message into an HL7 ADT (and potentially RAS) message. The intended usage is for software vendors engaged on either side of the interchange to provide alternative standard messages, both inbound and outbound.

Users of this document should consult the OASIS and HL7 references listed below for further information and clarification. This document is shared between OASIS and HL7 and is available to system implementers. It is important that developers obtain the proper OASIS or HL7 standards documents cited below, as they provide the detail and the framework for the mapping cited in this document.

1.3      References

[EDXL-CIQ]

OASIS Committee Specification Draft Emergency Data Exchange Language Customer Information Quality, December, 2011 http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/csd02/edxl-ciq-v1.0-csd02.html.

[EDXL-CT]

OASIS Committee Specification Draft Emergency Data Exchange Language Common Types, November, 2011

http://docs.oasis-open.org/emergency/edxl-ct/v1.0/csd02/edxl-ct-v1.0-csd02.html.

[EDXL-DE 1.0]

EDXL Distribution Element (DE) Standard v1.0, M. Raymond, S. Webb, and P. Aymond, Editors. March 2006. OASIS. http://www.oasis-open.org/specs/index.php#edxlde-v1.0.

[EDXL-DE 2.0]

Emergency Data Exchange Language Distribution Element, Committee Specification Version 2.0, J. Waters, Editor. OASIS, 19 September 2013, http://docs.oasis-open.org/emergency/edxl-de/v2.0/cs02/edxl-de-v2.0-cs02.html.

 [EDXL-TEP-v1.1]

Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Version 1.1. Edited by Werner Joerg. 04 August 2015. OASIS Committee Specification Draft 01 / Public Review Draft 01. http://docs.oasis-open.org/emergency/edxl-tep/v1.1/csprd01/edxl-tep-v1.1-csprd01.html. Latest version: http://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.html.

[HL7 v2.7.1]

HL7 Messaging Standard v2.7.1

[TEP/HL7 Transforms]

TEPv1.1-HL7v2.7.1-Transforms-v1.0.xls

When a patient transitions from emergency services to a hospital system, a transform from an EDXL-TEP 1.1 message to an HL7 2.7.1 ADT/A14 (Pending Admit - Event A14) message is required. If pharmaceuticals are administered enroute, a separate HL7 2.7.1 RAS/O17 (Pharmacy/Treatment Administration Message - Event O17) is needed to capture each administration. The ADT/A14 and RAS messages are linked within the hospital system via the Patient Identification (PID) element, which is consistent in both messages.

When a patient transitions from a hospital system to emergency services, a transform from an HL7 2.7.1 ADT/A03 (Discharge/End Visit - Event A03) message to an EDXL-TEP 1.1 message is required.

EDXL-TEP is designed to be routed using an EDXL Distribution Element (EDXL-DE) content wrapper. All transforms (EDXL-TEP to ADT/A14, EDXL-TEP to RAS/O17, and ADT/A03 to EDXL-TEP), require a DE transform, as well. The EDXL-DE is a general-purpose routing wrapper than can contain any type of electronic data payload.

Disaster situations may present in which hospitals are evacuated with regional or federal coordination, leave the evacuating hospitals unclear on the facility to which their patients are being evacuated. The EDXL-DE provides a mechanism for Electronic Health Records (EHR) to travel with the patient via emergency services as an EDXL-DE payload. The EHR is not transformed, but simply carried in its native format for delivery to the receiving HL7 system.

Five messaging use cases have been identified for patient tracking:

·         Hospital-to-hospital transfer

·         Incoming patients

·         Hospital transfers

·         Regional coordination

·         Federal support

2.1 Hospital-to-Hospital transfer

Hospital to hospital communication is strictly within the HL7 domain and is considered out-of-scope for the TEP/HL7 transform.

2.2 Incoming Patients

A second use case is patients arriving to the hospital ED via EMS. The EMS system uses EDXL-TEP and the hospital uses HL7. The incoming EDXL-TEP message is transformed into an HL7 ADT/A14 message type for ingest by the hospital system. If pharmaceuticals are administered enroute, a second RAS/O17 message is also generated.

2.3 Hospital Transfers

A third use case is patients transferring from one hospital to another via EMS. An HL7 ADT/A03 message type is transformed into a EDXL-TEP message to provide information to EMS, and the EDXL-TEP message is again transformed into an HL7 ATD/A14 message type for ingest by the receiving hospital system. This is the situation of day-to-day transfers, so the complete electronic health record can be exchanged directly between hospitals via HL7. If pharmaceuticals are administered enroute, a second RAS/O17 message is also generated.

 

2.4 Regional Coordination

In an emergency, the evacuation, transfer and transport may be coordinated through Emergency Management or regional healthcare coalition coordination. In this situation, an HL7 ADT/A03 message type is transformed into a EDXL-TEP message to provide information to the transport coordinator, and the EDXL-TEP message is again transformed into an HL7 ADT/A14 message type for ingest by the receiving hospital system. If pharmaceuticals are administered enroute, a second RAS/O17 message is also generated.

2.5 Federal Support

Similar to the regional transfer and evacuation, long distance evacuation coordination can be facilitated via HL7/TEP and TEP/HL7 transforms using federal support (e.g., JPATS support). In this situation, an HL7 ADT/A03 message type is transformed into a EDXL-TEP message to provide information to the transport coordinator, and the EDXL-TEP message is again transformed into an HL7 ADT/A14 message type for ingest by the receiving hospital system. If pharmaceuticals are administered enroute, a second RAS/O17 message is also generated.

3.1 OASIS EDXL-TEP

3.1.1 The EDXL Family of Emergency Management Messaging Standards

EDXL-TEP is a member of the Emergency Data eXchange Language (EDXL) family of OASIS Standards. Their ongoing goal is to facilitate emergency sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. This goal is achieved by focusing on the standardization of specific messages to facilitate emergency communication and coordination, particularly when more than one profession or governmental jurisdiction is involved.

OASIS EDXL-TEP defines an XML messaging standard that records and exchanges all key aspects of patient information and care from initial encounter with emergency services who utilize EDXL-TEP for patient transport(s) throughout the continuum of care to the point of admittance to a healthcare facility that provides ongoing and post-emergency care, and up to release.

3.1.2 EDXL-TEP Development

Through a practitioner-driven approach, the Command, Control and Interoperability Division (CID) within the U.S. Department of Homeland Security's Science and Technology Directorate creates and deploys information resources to enable seamless and secure interactions among state, local, tribal, international, private entities, homeland security stakeholders and other federal entities. The CID’s Office for Interoperability and Compatibility (OIC) serves as the standards program within the Federal Government to facilitate public safety and emergency response agencies to improve emergency / disaster response through effective and efficient interoperable data sharing. OIC sponsors the process to facilitate practitioner requirements for the development of EDXL standards.

The EDXL program is an open, public practitioner-driven process driven solely by cross-profession emergency practitioners through an OIC-sponsored Practitioner Steering Group (PSG) and Standards Working Group (SWG). The EDXL program is also a public-private partnership working with the Emergency Interoperability Consortium (EIC), Vendor communities, and OASIS.

A consensus-based process and drivers are used to narrow down CORE minimal set of elements needed across local, state and federal systems, KISS, required (minimal) and optional elements – what the field is able to provide given their first priority is to save lives.

The draft OASIS EDXL-TEP standard has completed multiple NDMS live exercises in field tests and one draft implementation, and it is anticipated that there will be adoption in multiple countries.

3.1.3 Current status

EDXL-TEP 1.1 has been approved as a Committee Standard Draft (csd01) by the EM-TC and is being submitted for public review under OASIS for acceptance as an OASIS Committee Standard (cs01). EDXL-TEP v1.1 is expected to traverse the standardization process by mid-2016.

3.2 HL7 V2.7.1 Healthcare Messaging Standard

Founded in 1987, Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice evaluation of health services.

3.2.1 The HL7 messaging Standard

HL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems.

3.2.2 Current Status

Version 2.7, representing the latest update to the Version 2 Standard, was published in 2011. Version 2.7.1 has been superseded by version 2.8 as the most current version in the V2 messaging family.  However, standards and specifications based on version 2.7.1 will be "current" for many years to come. Until replaced by direct replacements, specifications (like this one), implementation guides, and messaging protocols based on a v2.7.1 can remain in place until there is a need to take advantage of features of later versions of the Messaging Standard.

 

The details of the transformations specified by this document are in a spreadsheet (TEP-HL7v2-TransformsV10.xls) that accompanies this document.  This spreadsheet is structured into several tabs, one of which (“Introduction”) summarizes the use of the document; one holds the transformation details for the current HL7 version (V2.7.1); and the remaining ones will be used for auxiliary complex data types (typically generic reusable elements such as “Location”, “Contact” or “Person” information), transformation oddities and space for tracking, commenting and maintenance of the document.

4.1 Spreadsheet Tabs Summary

The spreadsheet consists of an “Introduction” tab, and a set of seven (7) transform tabs:

1          Spreadsheet Tab	2          Content Summary
3           Introduction	4           The “Introduction” tab lists the purpose of the document, describes the color coding used in the transform tab, and shows the HL7 component key.
5           EDXL-TEP <--> ADT	6           The “EDXL-TEP <--> ADT” message tab contains the primary mapping information. It is used for transforming EDXL-TEP to HL7/ADT A14, and for transforming HL7/ADT A03 to EDXL-TEP. Mappings of EDXL-RM complex structures of the following data types are contained in alternate tabs, using consistent Sort numbering: ct:PersonDetails, ct:EDXLLocation, and xal:Address. A separate Hl7/RAS message type must be generated to communicate information on pharmaceuticals administered during transport (see “EDXL-TEP --> RAS Message” message tab).
7           EDXL-TEP --> RAS Message	8           The “EDXL-TEP --> RAS Message” message tab contains the mapping information needed to communicate information on pharmaceuticals administered during transport. It is used for transforming EDXL-TEP to HL7/RAS. There is not use case for transforming HL7/RAS to EDXL-TEP. Information on pharmaceuticals administered during hospital care are communicated via the full electronic health record directly with the receiving hospital. If the receiving hospital is unknown, as in the case of a large scale evacuation with regional or federal coordination, the EHR can be bundled in the EDXL-DE for routing with the coupled EDXL-TEP message. Mappings of EDXL-RM complex structures of the following data types are contained in alternate tabs, using consistent Sort numbering: ct:PersonDetails and ct:EDXLLocation.
9           ct-PersonDetails <--> HL7 V2.7.1	10        The “ct-PersonDetails <--> HL7 V2.7.1” tab contains the transformation between the EDXL-TEP ct:PersonalDetails complex structure and HL7 ADT and RAS messages. Sort numbering is consistent between tabs for easy cross-referencing.
11       ct-EDXLLocation <--> HL7 V2.7.1	12        The “ct-EDXLLocation <--> HL7 V2.7.1” tab contains the transformation between the EDXL-TEP ct:EDXLLocation complex structure and HL7 ADT and RAS messages. Sort numbering is consistent between tabs for easy cross-referencing.
13       xal-Address <--> HL7 V2.7.1	14        The “xal-Address <--> HL7 V2.7.1” tab contains the transformation between the EDXL-TEP ct:EDXLLocation complex structure and HL7 ADT messages. Sort numbering is consistent between tabs for easy cross-referencing.
15       EDXL-DE 1.0 <--> HL7 V2.7.1	16        The “EDXL-DE 1.0 <--> HL7 V2.7.1” tab contains the transformation between the EDXL-DE v 1.0 and HL7 messages. The EDXL-DE is a content wrapper that is used for routing messages. If an EDXL-TEP message is routed using an EDXL-DE v. 1.0, this tab is used for the transform.
17       EDXL-DE 2.0 <--> HL7 V2.7.1	18        The “EDXL-DE 2.0 <--> HL7 V2.7.1” tab contains the transformation between the EDXL-DE v 2.0 and HL7 messages. The EDXL-DE is a content wrapper that is used for routing messages. If an EDXL-TEP message is routed using an EDXL-DE v. 2.0, this tab is used for the transform.

 

4.2 Transform Tabs

The transform tabs consists of three groups of columns: the EDXL-TEP Message details, the Transformations (TEP to ADT and ADT to TEP), and the ADT message details.

4.2.1 EDXL-TEP message details

-          TEP path / TEP data name

Name and hierarchical path for structured elements

-          Type

Type or format of the element

-          Usage

R = required, O = optional, C = conditional

-          Definition

Informal description of the element

-          Comments

                Additional comments and structural information

-          Cardinality

Refines the Usage notion with the inclusive interval notation [lb .. ub], where lb stands for lower bound (default 0) and ub stands for upper bound (default '*' - any > 1). For example, [1..1] means REQUIRED, exactly once, [0..*] means OPTIONAL, any number of times.

-          Valid Values / Examples

A list of values that apply to this particular element, or examples which apply in order to clarify the definition. Where valid values are specified for ValueListURN/Value type pairs, these values are suggested as defaults, allowing implementations to use their own value list, or insert their own value by extending the defaults.

4.2.2 The ADT message details

      -  HL7 Element Name

      -  Segment.Seq:  position

Ordinal position of the data field within the segment. This number is used to refer to the data field in the text comments that follow the segment definition table.

      -  Sub.Seq: sub-position

      -  Len: normative length

If applicable, the number of characters that one occurrence of the data field or component may occupy if populated.

For some fields or components, the value domain of the content leads to clearly established boundaries for minimum and/or maximum length of the content. In these cases, these known limits are specified for the item. Normative lengths are only specified for primitive data types.

      -  C.Len: conformance length

If applicable, the conformance length that applies to the field or component.

If populated, the conformance length column specifies the minimum length that applications must be able to store. Conformant applications SHALL not truncate a value that is shorter than the length specified. The conformance length is also the minimum value that maybe assigned to maximum length in an implementation profile.

In addition, the conformance length may be followed by a “=” or a “#”. The “=” denotes the value may never be truncated, and the “#” denotes that the truncation behaviour defined for the data type applies.

Applications are not required to implement the truncation pattern, even if it may be applied to an item. Applications should declare their adoption of the truncation pattern in their conformance profiles.

      -  Data Type: data type

The basic building block used to construct or restrict the contents of a data field.

      -  Opt: optionality

Whether the field is required, optional, or conditional in a segment.

      -  RP/#: repetition

Whether the field may repeat. The value that appears in the repetitions column is the maximum number of allowed occurrences, e.g., a value of '3' would mean that the field can have '3 occurrences'; if unspecified, there is only one occurrence, i.e., cannot repeat.

N or blank - no repetition

Y - the field may repeat an indefinite or site-determined number of times

(integer) - the field may repeat up to the number of times specified by the integer

      -  TBL#: table identifier

      -  Comments

      -  OID: object identifier

4.2.3 5.1.3 Transformations

There are 2 columns that define the transformations that capture the bidirectional mapping between OASIS/TEP and HL7/ADT. Additional comments list particularities relevant to the transformation rules.

      -  Transformation OASIS/TEP to HL7

The cells in this column summarize the transformation task for the EDXL-TEP structure listed to the left of the row (“TEP path / TEP data name”) to the corresponding ADT structure, if existent, listed to the right of the row “HL7 Element Name”).

      -  Transformation:  HL7 to OASIS/TEP

The cells in this column summarize the transformation task for the ADT structure listed to the right of the row (under “HL7 Element Name”) to the corresponding EDXL-TEP structure, if existent, listed to the left of the row (under “TEP path / TEP data name”).

 

 

This section is not normative. If any differences exist between the content of this section and with the EDXL-TEP v1.1 or EDXL-DE (v1.0 or v2.0) standards, the standards are the authoritative source.

5.1 EDXL Elements

EDXL messages are constructed of well-formed XML. An EDXL XML element is structured by using Complex elements, ValueListURIs, and atomic elements.  The focus of the TEP/HL7 mapping is on the atomic elements.

5.1.1 Atomic Elements

Atomic elements carry data. Their types are either

i)        Predefined simple types in the XMLSchema space “xsd:” (http://www.w3.org/2001/XMLSchema)

-          xsd:token

-          xsd:anyURI

-          xsd:string

-          xsd:unsignedInt

-          xsd:boolean

-          xsd:date

-          xsd:dateTime

-          xsd:integer

-          xsd:float

-          xsd:enumeration

or

ii)       Constrained simple types in the EDXL Common Type space “ct:”

-          ct:EDXLStringType (derived from xsd:string)

-          ct:EDXLDateTimeType (derived from xsd:dateTime)

-          ct:ValueType

-          ct:ValueListURI

-          ct:PercentageType

-          ct:DegreesCType

-          ct:EstimateType

ValueListURI is used by EDXL-TEP to identify a value set and is discarded in the transformation to ADT.  In the other direction, the value of ValueListURI is supplied in the transformation specs.

5.1.2 Complex Elements

A xsd:complexType, which is comprised of two or more atomic elements to fulfill the concept or element purpose.  The complexType itself is not atomic, and is not itself used as a tag to place or carry data. It is used to describe the hierarchical (tree) structure of a EDXL-TEP message, where complexTypes represent branches and atomic types represent leaves.

EDXL-TEP specific branches are preceded with the “tep:” prefix. Their contents may reference types from other name spaces such as xsd:, ct: (see EDXL-CT), or xal: (see EDXL-CIQ).

5.1.3 A note about lists

(Derived from [EDXL-TEP], Section 3.2.2 Selecting values from lists)

The ValueList and ValueKey types are part of the EDXL Common Types collection. They allow standards adopters to use topic specific lists of values for elements such as raceEthnicity, fluentSpokenLanguages, specialTransportationNeeds, 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.

Their structures are therefore very similar:

      ct:ValueListType

            valueListURI [1..1]: ct:ValueListURI

            value [1..*]: ct:ValueType

      ct:ValueKeyType

            valueListURI [1..1]: ct:ValueListURI

            value [1..1]: ct:ValueType

ValueListURI is used by EDXL-TEP to identify the value set and is discarded in the transformation to ADT.  In the other direction the value of ValueListURI is supplied in the transformation specs. It is strongly recommended that communication trading partners agree (TPA) in advance what these value lists will contain, where it will be located, and who will manage the list.

5.1.4 A note about Extensions

(Derived from [EDXL-TEP], Section 3.2.3 EDXL Extensions)

The challenge when developing standardized formats is to balance the need to define specific elements of emergency information that we can all agree upon and yet provide flexibility for local communities to include their particular information using their familiar vocabulary. EDXL addresses this concern by providing the common defined terms in the formal standards for the former, and by providing extension mechanisms for the latter.

Typical needs are:

 

1. Community augmentation: community adds new information that is associated with the EDXL standard. Examples: adding HL7 translation information to the EDXL-TEP.

2. List augmentation: community adds new values (enumerations) to the default set of values in the standard. Example: adding FlightRisk value to the EDXL-TEP contingencyMedicalSpecialityCode list.

3. List replacement: community replaces the default set of values in the standard in its entirety.

Example: defining TriageStatus with number codes instead of colors.

4. List redefinition: community reassigns the meaning of the default set of values in the standard in its entirety. Example: redefining the Black TriageCode to mean actively dying but not yet deceased.

EDXL combines the CommunityExtension mechanism with the ValueList and ValueKey types to deal with these needs. CommunityExtension addresses need 1.; ValueList / ValueKey address need 3. ; and combined they address needs 2. and 4.

A “CommunityExtension”, or simply “Extension”, is a term used to describe supplemental message information that a community wants to add to the otherwise standard message information normally contained within an EDXL standard message. It is defined by the ExtensionType which consists of a [1..*] set of name/value pairs.

The schema for ExtensionType is defined as

    <xs:complexType name="ExtensionType">

        <!-- Base type to allow communities to extend/augment an EDXL data standard -->

        <xs:sequence>

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

                <!-- Unique community identifier -->

            </xs:element>

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

                <!-- Unique identifier for this extension -->

            </xs:element>

            <xs:element name="parameter" type="ext:ParameterType"  

maxOccurs="unbounded"/>

        </xs:sequence>

    </xs:complexType>

 

   where "ParameterType" is defined as a group of elements used to

   extend/augment the data standard

 

        <xs:sequence>

            <xs:element name="nameURI" type="ext:ParameterNameType">

                <!-- Unique identifier of a parameter -->

            </xs:element>

            <xs:element name="value" type="ext:ParameterValueType"

                maxOccurs="unbounded"/>

        </xs:sequence>

 

   with "ParameterNameType" being defined as a URI with optional

   xPath attribute and "ParameterValueType" being defined as a

  ct:EDXLStringType" with optional "uom" attribute.

 

Its application to the XML description of an element elementName of type ext:ExtensionType would be:

 

    <ext:ExtensionType

             xmlns=”urn:oasis:names:tc:emergency:edxl:extension:1.0”>

        <community>communityURI</community>

        <id>extensionURI</id>

        <parameter>

            <nameURI>name</nameURI>

            <value>value</value>

        </parameter>

            ...

        <parameter> … </parameter>

    </ext:ExtensionType>

 

If that extension is to be used for adding a community specific item in an enumeration, we indicate this by adding

 

    <xsd:enumeration value="ExtensionValue"/>

 

to the enumeration affected.

For illustration let’s consider a special application of Extension: it can be used for tasks such as translating EDXL-TEP message structures to/from HL7 structures. Here are two examples that address the TEP/HL7 translation problem for HL7 v2 and HL7 v3.

- HL7 v2:

    <TEPMessage>

        <extension>

            <community>TEP:v11:HL7:V271</community>

            <id>layer2</id>

            <parameter>

                <nameURI xPath="./patient/patientID/ID">patientIDNumber</nameURI>

                <value>Patient Identifier List | ID Number</value>

            </parameter>

        </extension>

            ...

        <patient>

            <patientID>

                <ID>some id</ID>

            </patientID>

        </patient>

    </TEPMessage>

 

- HL7 v3:

    <TEPMessage>

        <extension>

            <community>TEP:v11:HL7:V3</community>

            <id>layer2</id>

            <parameter>

                <nameURI xPath="./patient/patientID/ID">patientIDNumber</nameURI>

                <value>person.id</value>

            </parameter>

        </extension>

            ...

        <patient>

            <patientID>

                <ID>some id</ID>

            </patientID>

        </patient>

    </TEPMessage>

5.2 EDXL-TEP

5.2.1 EDXL-TEP message structure

tep:TEPMessage

-          messageID [1..1]: ct:EDXLStringType

-          systemID [0..1]: ct:EDXLStringType

-          patient [1..1]: tep:PatientType

-          patientID [1..*]: tep:PatientIDType

-          ID [1..1]: ct:EDXLStringType

-          source [1..1]: ct:ValueListType

-          gender [1..1]: tep:GenderDefaultValues

-          patientAge [1..1]: tep:PatientAgeType

-          age [1..1]: xsd:unsignedInt

-          estimated [1..1]: ct:EstimateType

-          units [1..1]: tep:AgeUnitsDefaultValues

-          raceEthnicity [0..1]: ct:ValueListType

-          dateOfBirth [0..1]: xsd:date

-          personalID [0..1]: ct:PersonDetailsType

-          hairColor [0..1]: ct:ValueKeyType

-          eyeColor [0..1]: ct:ValueKeyType

-          distinguishingMarks [0..1]: ct:EDXLStringType

-          fluentSpokenLanguages [0..1]: ct:ValueListType

-          specialTransportationNeeds [0..1]: ct:ValueListType

-          specialMedicalNeeds [0..1]: ct:ValueListType

-          medicationAllergies [0..1]: ct:ValueListType

-          currentMedication [0..*]: tep:MedicationType

-          familyUnificationCode [0..1]: ct:EDXLStringType

-          barriersToPatientCare [0..1]: ct:ValueListType

-          evacuationDestinationRequired [0..1]: tep: PatientEvacuationDestinationRequiredDefaultValues

-          patientContactInformation [0..1]: ct:PersonDetailsType

-          closestRelativeGuardianContactInformation [0..*]: +ct:PersonDetailsType

-          specialClassification [0..*]: +tep:specialClassificationDefaultValues

-          situation [1..1]: tep:SituationType

-          incidentID [1..*]: tep:IncidentIDType

-          name [1..1]: ct:EDXLStringType

-          ID [1..1]: ct:EDXLStringType

-          kind [1..1]: ct:ValueListType

-          source [1..1] ct:EDXLStringType

-          incidentLocation [1..1]: ct:EDXLLocationType

-          incidentStartDateTime [0..1]: ct:EDXLDateTimeType

-          -- relatedIncidentID [0..*]: ct:EDXLStringType

-          healthCareProvider [1..1]: tep:HealthCareProviderType

-          providerNumber [1..1]: ct:ValueKeyType

-          providerName [1..1]: ct:EDXLStringType

-          providerJurisdiction [1..1]: xal:AddressType

-          providerCountry [1..1]: ct:ValueKeyType

-          providerKind [1..1]: ct:ValueListType

-          providerDomainName [0..1]: ct:EDXLStringType

-          personnelIDNumber [0..1]: ct:EDXLStringType

-          personnelJurisdiction [0..1]: xal:AddressType

-          personnelCertificationLevel [0..1]: ct:ValueListType

-          transport [0..1]: tep:TransportType

-          unitNumber [0..1]: ct:EDXLStringType

-          vehicleKind [0..1]: ct:ValueKeyType

-          vehicleProvider [0..1]: ct:EDXLStringType

-          vehicleJurisdiction {1..1]: xal:AddressType

-          patientEncounter [1..1]: tep:PatientEncounterType

-          encounterID [1..1]: ct:EDXLStringType

-          encounterDateTime [1..1]: ct:EDXLDateTimeType

-          locationCategory [1..1]: ct:ValueKeyType

-          encounterLocation [1..1]: ct:EDXLLocationType

-          patientCare [1..*]: tep:PatientCareType

-          patientCareRecordID [1..1]: ct:EDXLStringType

-          patientCareRecordDateTime [1..1]: ct:EDXLDateTimeType

-          triageStatus [1..1]: tep:TriageStatusDefaultValues

-          patientCurrentDisposition [1..1]: tep:PatientCurrentDispositionDefaultValues

-          chiefComplaint [0..1]: ct:EDXLStringType

-          systolicBloodPressure [0..1]: xsd:integer constrained

-          diastolicBloodPressure [0..1]: xsd:integer constrained

-          pulseRate [0..1]: xsd:integer constrained

-          respiratoryRate [0..1]: xsd:integer constrained

-          cardiacMonitorRhythm [0..1]: ct:ValueListType

-          twelveLeadECGInterpretation [0..1]: +ct:EDXLStringType

-          pulseOximetry [0..1]: ct:PercentageType

-          CO2Level [0..1]: xsd:unsignedInteger

-          bloodGlucoseLevel[0..1]: xsd:integer constrained

-          temperature [0..1]: ct:DegreesCType

-          totalGCS [0..1]: xsd:integer constrained

-          medicationAdministered [0..*]: tep:MedicationAdministeredType

-          proceduresPerformed [0..1]: ct:ValueListType

-          careProviderPrimaryImpression [0..1]: +ct:ValueListType

-          seriousConcerns [0..1]: ct:EDXLStringType

-          contaminationRadiationContagionStatus [0..1]: +xsd:boolean

-          acsCDCFieldTraumaCriteria [0..1]: xsd:boolean

-          contigencyMedicalSpecialtyCode [0..1]: tep: contigencyMedicalSpecialtyCodeDefaultValues

-          patientTransfer [0..*]: tep:PatientTransferType

-          destinationETA [0..1]: ct:EDXLDateTimeType

-          destination [1..1]: ct:EDXLLocationType

-          actualArrivalDateTime [0..1]: ct:EDXLDateTimeType

-          actualDepartureDateTime [0..1]: +ct:EDXLDateTimeType

-          extension [0..*]: ext:ExtensionType  (cf. section 4.1.1.4 below)

5.2.2 Auxiliary EDXL-TEP message structures

tep:AgeUnitsDefaultValues: xsd:enumeration

tep:MedicationType

-          name [1..1]: ct:ValueKeyType

-          dosage [0..1]: ct:EDXLStringType

-          route [0..1]: ct:ValueKeyType

-          frequency [0..1]: ct:EDXLStringType

tep:MedicationAdminsteredType

-          medication [1..1]: tep:MedicationType

-          administered [0..*]: ct:EDXLDateTimeType         

tep:PatientEvacuationDestinationRequiredDefaultValues:  xsd:enumeration

tep:specialClassificationDefaultValues: xsd:enumeration

tep:triageStatusDefaultValues: xsd:enumeration

tep:PatientCurrentDispositionDefaultValues: xsd:enumeration

5.2.3 Auxiliary shared EDXL structures

ct:PersonDetailsType

-          PersonName [1..*]: xNL:PersonNameType

-          NameElement [0..*]: xsd:normalizedString

-          ElementType [0..1]: xsd:normalizedString

-           Addresses [0..1]: xsd:ComplexType

-          Address [0..*]: xal:AddressType

-          ContactNumbers [0..1]: xsd:ComplexType

-          ContactNumber [1..*]: xsd:ComplexType

-          ContactNumberElement [0..*]: xsd: normalizedString

-          Type [0..1]: xsd: normalizedString

-          CommunicationMediaType [0..1]: xsd: normalizedString

-          Usage [0..1]: xsd: normalizedString

-          ContactHours [0..1]: xsd: normalizedString

-          ElectronicAddressIdentifiers [0..1]: xsd:ComplexType

-          ElectronicAddressIdentifier [1..*]: xsd: normalizedString

-          Kind [1..1]: xsd: normalizedString

-          Usage [1..1]: xsd: normalizedString

-          Identifiers [0..1]: xsd:ComplexType

-          Identifier [1..*]: xsd:ComplexType

-          IdentifierElement [0..1]: xsd: normalizedString

-          Type [0..1]: xsd: normalizedString

-          IssuerName [0..1]: xsd:ComplexType

-          NameElement [0..*]: xsd: normalizedString

-          SubDivisionName [0..*]: xsd: normalizedString

-          OrganisationID [0..1]: xsd: normalizedString

-          OrganisationIDType [0..1]: xsd: normalizedString

-          Type [0..1]: xsd: normalizedString

 

ct:EDXLLocationType

-          EDXLGeoLocation [0..1]: xsd:ComplexType

-          Point[0..1]: xsd:ComplexType

-          pos [1..1]: xsd:list (doubles)

-          CircleByCenterPoint [0..1]: xsd:ComplexType

-          pos [1..1]: xsd:list (doubles)

-          radius [1..1]: xsd:double

-          uom [1..1]: xsd:string or xsd:anyURI

-          Polygon [0..1]: xsd:ComplexType

-          exterior [0..1]:xsd:ComplexType

-          LinearRing [1..1]: xsd: normalizedString

-          pos [4..*]: xsd:list (doubles)

-          Envelope [0..1]: xsd:ComplexType

-          lowerCorner [1..1]: xsd:list (doubles)

-          upperCorner [1..1]: xsd:list (doubles)

-          LineString [0..1]: xsd:ComplexType

-          pos [2..*]: xsd:list (doubles)

-          posList [1..1]: xsd:list (doubles)

-          count [0..1]: xsd:positiveInteger

-          EDXLGeoPoliticalLocation [0..1]: xsd:ComplexType

-          GeoCode [0..1]: xsd:ComplexType

-          ValueListURI [1..1]: xsd:anyURI

-          Value [1..*]: xsd:string

-          Address [0..1]: xal:AddressType

 

xal:addressType

-          FreeTextAddresses [0..1]: xsd:ComplexType

-          AddressLine [1..*]: xsd:normalizedString

-          Country [0..1]: xsd:ComplexType

-          NameElement [1..1]: xsd:normalizedString

-          AdministrativeArea [0..1]: xsd:ComplexType

-          NameElement [1..*]: xsd:normalizedString

-          SubAdministrativeArea [0..1]: xsd:ComplexType

-          NameElement [1..*]: xsd:normalizedString

-          Locality [0..1]: xsd:ComplexType

-          NameElement [1..*]: xsd:normalizedString

-          SubLocality [0..1]: xsd:ComplexType

-          NameElement [1..*]: xsd:normalizedString

-          Thoroughfare [0..1]: xsd:ComplexType

-          NameElement [1..*]: xsd:normalizedString

-          Abbreviation [0..1]: xs:boolean

-          NameType [0..1]: xsd: normalizedString

-          Number [1..*]: xsd:ComplexType

-          Identifier [0..1]: xsd: normalizedString

-          Type [0..1]: xsd: normalizedString

-          Abbreviation [0..1]: xsd: normalizedString

-          Type [0..1]: xsd:normalizedString

-          PostCode [0..1]: xsd:ComplexType

-          Identifier [1..*]: xsd: normalizedString

-          Type [0..1]: xsd: normalizedString

-          Abbreviation [0..1]: xsd: normalizedString

 

5.3 EDXL-DE

EDXL-TEP is designed to be routed using an EDXL Distribution Element (EDXL-DE) content wrapper. There are 2 versions of the EDXL-DE currently being used: EDXL-DE 1.0 (2006) and EDXL-DE 2.0 (2014). The TEP/HL7 transform provides mapping between HL7 2.71 and both versions of the EDXL-DE.

EDXL-DE 1.0 structure is shown below:

-          distributionID [1..1]: xsd:string

-          senderID [1..1]: xsd:string

-          dateTimeSent [1..1]: xsd:dateTime

-          distributionStatus [1..1]: statusValues

-          distributionType [1..1]: typeValues

-          combinedConfidentiality [1..1]: xsd:string

-          language [0..1]: xsd:string

-          senderRole [0..*]: valueListType

-          valueListURN [1..1]: xsd:string

-          value [1..1]: xsd:string

-          recipientRole [0..*]: valueListType

-          valueListURN [1..1]: xsd:string

-          value [1..1]: xsd:string

-          keyword [0..*]: valueListType

-          valueListURN [1..1]: xsd:string

-          value [1..1]: xsd:string

-          distributionReference [0..*]: xsd:string

-          explicitAddress [0..*]: valueSchemeType

-          explicitAddressScheme [1..1]: xsd:string

-          value [1..*]: xsd:string

-          targetArea [0..*]: targetAreaType

-          circle [0..*]: xsd:string

-          polygon [0..*]: xsd:string

-          country [0..*]: xsd:string

-          subdivision [0..*]: xsd:string

-          locCodeUN [0..*]: xsd:string

-          contentObject [0..*]: contentObjectType

-          contentDescription [0..1]: xsd:string

-          contentKeyword [0..*]: valueListType

-          valueListURN [1..1]: xsd:string

-          value [1..1]: xsd:string

-          incidentID [0..1]: xsd:string

-          incidentDescription [0..1]: xsd:string

-          originatorRole [0..*]: valueListType

-          valueListURN [1..1]: xsd:string

-          value [1..1]: xsd:string

-          consumerRole [0..*]: valueListType

-          valueListURN [1..1]: xsd:string

-          value [1..1]: xsd:string

-          confidentiality [0..1]: xsd:string

-          other [0..1]: xsd:other

-          nonXMLContent [0..1]: nonXMLContentType

-          mimeType [1..1]: xsd:string

-          size [0..1]: xsd:integer

-          digest [0..1]: xsd:integer

-          uri [0..1]: xsd:anyURI

-          contentData [0..1]: xsd:base64Binary

-          xmlContent [0..1]: xmlContent

-          keyXMLContent [0..*]: anyXMLType

-          embeddedXMLContent [0..*]: anyXMLType

    

EDXL-DE 2.0 structure is shown below:

-          distributionID [1..1]: ct:EDXLStringType

-          senderID [1..1]: ct:EDXLStringType

-          dateTimeSent [1..1]: ct:EDXLDateTimeType

-          dateTimeExpires [1..1]: ct:EDXLDateTimeType

-          distributionStatus [1..1]: DistributionStatusType

-          distributionKind [1..1]: DistributionKindType

-          descriptor [0..1]: DEDescriptorType

-          combinedConfidentiality [0..1]: ConfidentialityType

-          language [0..1]: xsd:language

-          senderRole [0..*]: ct:ValueListType

-          valueListURI [1..1]: ct:ValueListURIType

-          value [1..*]: ct:ValueType

-          recipientRole [0..*]: ct:ValueListType

-          valueListURI [1..1]: ct:ValueListURIType

-          value [1..*]: ct:ValueType

-          keyword [0..*]: ct:ValueListType

-          valueListURI [1..1]: ct:ValueListURIType

-          value [1..*]: ct:ValueType

-          explicitAddress [0..*]: ct:ValueSchemeType

-          explicitAddressScheme [1..1]: ct:EDXLStringType

-          value [1..*]: ct:EDXLStringType

-          targetAreas [0..*]: targetAreasType

-          areaKind [1..1]: AreaKindType

-          areaGrouping [1..1]: AreaGroupingType

-          targetArea [1..*]: TargetAreaType

-          EDXLGeoLocation [0..1]: gsf:EDXLGeoLocation

-          EDXLGeoPoliticalLocation [0..1]: ct:EDXLGeoPoliticalLocation

-          urgency [0..1]: UrgencyType

-          severity [0..1]: SeverityType

-          certainty [0..1]: CertaintyType

-          incidentID [0..*]: ct:EDXLStringType

-          incidentDescription [0..*]: ct:EDXLStringType

-          link [0..*]: DELinkType

-          extension [0..*]: xmlStructure

-          community [1..1]: xsd:anyURI

-          id [1..1]: xsd:anyURI

-          parameter [1..*]: ParameterType

-          name [1..1]: Complex Type

-          URI [1..1]: ParameterNameType

-          anyURI [1..1]: xsd:anyURI

-          xPath [0..1]: xsd:string

-          value [1..1]: ParameterValueType

-          EDXLStringType [1..1]: ct:EDXLStringType

-          uom [0..1]: xsd:string

-          content [0..1]: DEContentType

-          contentObject [1..*]: DEContentObjectType

-          contentDescriptor [1..1]: DEContentDescriptorType

-          contentDescription [0..1]: ct:EDXLStringType

-          contentKeyword [0..*]: ct:ValueListType

-          ValueListURI [1..1]: ct:ValueListURIType

-          Value [1..*]: ct:ValueType

-          originatorRole [0..*]: ct:ValueListType

-          ValueListURI [1..1]: ct:ValueListURIType

-          Value [1..*]: ct:ValueType

-          consumerRole [0..*]: ct:ValueListType

-          ValueListURI [1..1]: ct:ValueListURIType

-          Value [1..*]: ct:ValueType

-          contentID [0..*]: ct:EDXLStringType

-          confidentiality [0..1]: ConfidentialityType

-          contentLanguage [0..1]: xsd:language

-          other [0..*]: ext:extension

-          contentXML [0..1]: XML Structure

-          keyXMLContent [0..1]: AnyXMLType

-          embeddedXMLContent [1..1]: AnyXMLType

-          otherContent [0..1]: OtherContentType

-          mimeType [1..1]: ct:EDXLStringType

-          size [0..1]: xsd:integer

-          digest [0..1]: xsd:integer

-          uri [0..1]: xsd:anyURI

-          contentData [0..1]: xsd:base64Binary

-          other [0..*]: AnyXMLType

-          link [0..*]: DELinkType

-          other [0..*]: AnyXMLType

 

This section is not normative. If any differences exist between the content of this section and with the HL7 v2.7.1 standard, the standard is the authoritative source.

6.1 ADT/A14 – Pending Admit

 

1.4      ADT/A03 – Discharge/End Visit

 

1.5      RAS/017 – Pharmacy/Treatment Administration

 

 

The EDXL-TEP message provides a rich set of information that can be useful in managing the evacuation of medical patients. Many of the EDXL-TEP elements map to existing HL7 ADT and RAS message structures. Additional EDXL-TEP information that does not map directly to an existing HL7 field, can be captured in the observation (OBX) structure within HL7 message structures. There is concern that a flood of OBX information that is not valuable to a receiving Emergency Department (ED) would mask important information provided as OBX. The HL7 Emergency Care (EC) Working Group has provided guidance on which EDXL-TEP element should be mapped to HL7 OBX structures for patients incoming to a hospital. The EC Working Group recommends that the following EDXL-TEP elements not be mapped to the HL7 OBX message structure.

• hairColor
• eyeColor
• distinguishingMarks
• specialTransportationNeeds
• situation.incidentID.ID
• situation.incidentID.source
• situation.incidentStartDateTime
• situation.relatedIncidentID
• healthCareProvider.providerNumber
• healthCareProvider.providerJurisdiction
• healthCareProvider.providerDomainName
• healthCareProvider.personnelIDNumber
• healthCareProvider.personnelJurisdiction
• healthCareProvider.transport.vehicleProvider
• patientEncounter.patientTransfer.actualArrivalDateTime

The OASIS Emergency Management TC extends its thanks to the following HL7 Public Health and Emergency Response (PHER) Working Group Co-Chairs for their assistance.

Erin Holt, Tennessee Department of Health

Joginder Madra, Madra Consulting Inc.

Craig Newman, Northrop Grumman

Laura Rappleye, Altarum Institute

John Roberts, Tennessee Department of Health

Rob Savage, Rob Savage Consulting

 

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

OASIS Participants:

Norm Paulsen,  Environment Canada

Steve Hakusa, Google Inc.

Ka-Ping Yee, Google Inc.

Patti Aymond, IEM

Michael Alagna, IJIS Institute

Donald Gabbin, IJIS Institute

Daniel Potter, IJIS Institute

Don Sutherland, IJIS Institute

Gary Ham, Individual

Darrell O'Donnell, Individual

Rex Brooks, Individual

William Cox, Individual

Thomas Ferrentino, Individual

Timothy Grapes, Individual

Robert Torchon, Individual

Jacob Westfall, Individual

Elysa Jones, Individual

Massimo Cristaldi, Intelligence for Environment & Security-IES Solutions srl

Lizzie DeYoung, Mitre Corporation

Robert Gustafson, Mitre Corporation

Emily Laughren, Mitre Corporation

Brian Wilkins,  Mitre Corporation

Robert Bunge, NOAA's National Weather Service

Mike Gerber, NOAA's National Weather Service

Herbert White, NOAA's National Weather Service

Cory Casanave, Object Management Group

David Askov, Pacific Disaster Center

Dominic König, Sahana Software Foundation

Glenn Pearson, Sahana Software Foundation

Mark Prutsalis,  Sahana Software Foundation

Nuwan Waidyanatha, Sahana Software Foundation

David Barnes, United Kingdom Cabinet Office

James Penman, United Kingdom Cabinet Office

Toby Considine, University of North Carolina at Chapel Hill

Jeff Waters, US Department of Defense (DoD)

Mark Lucero, US Department of Homeland Security

Thomas Merkle, US Department of Homeland Security

Steve Streetman, US Department of Homeland Security

Richard Vandame, US Department of Homeland Security

 

HL7 Participants:

 

Rita Altamore, WA DOH

Butch Arthur, MS DOH

Sen Atanu

Wendy Blumenthal, CDC/Cancer Program

Nathan Bunker, AIRA

Hector Cintron, Accenture

Laura Conn, CDC

Erin Holt Coyne, Tennessee Department of Health

Virginia Dato, University of Pittsburgh Medical School

Lura Daussat, OZ Systems

Alexander de Leon, Kaiser Permanente

Annie Fine, NYC DOH

MariBeth Gagnon, CDC

Daniel Golson, TN DOH

Eric M Haas, MS, DVM, Haas Consulting

John Hatem, Oracle

Laura Hermann Langford RN, PhD, Intermountain Healthcare

Ray Humphrys

Mario Hyland, AEGIS

Sara Imholtz, AZ DOH

Rebecca E Johnson

Mark Jones, Orchid Software

Hetty Kahn, CDC

Laura Kenyon, TN DOH

Ramya Kommareddi, Altarum

Austin Kreisler, SAIC/CDC

Joe Lamy, AEGIS

Nell Lapres, Epic

Eric Larson, CDC

John Loonsk, CGI Federal

Steve Macauley, Inductive Health

Joginder Madra, Madra Consulting Inc.

Zach May, ESAC

ROChelle May-Gentile, Altarum

Lloyd McKenzie, HL7 Canada

Riki Merrick, APHL

Scott Moss, Epic

Stuart Myerburg,  CDC

Lisa Nelson, Lantana Consulting Group

Craig Newman, EPIC

Nancy Orvis, DoD

Melva Peters, Gordon Point Informatics Ltd.

Ken Pool, OZ Systems

Amit Popat, EPIC

Laura Rappleye, Altarum Institute

Shakeel Rashed, AJCC

Marcus Rennick, ASTHO

John Ritter, APHL/CDC

John Roberts, Tennessee Department of Health

Mark Roche, ONC

Rob Savage, Rob Savage Consulting

Wendy Scharber, CDC/Cancer Program

Atanu Sen, Accenture/ONC

AbdulMalik Shakir, HI3 Solutions

Tony Steyermark

Sony Varghese

Max Walker, HL7 AU

Mead Walker, Mead Walker Consulting/CDC/NCHS

Kathy Walsh, Labcorp

Cathy Welsh, AND

Michelle Williamson, CDC/NCHS

 

Revision	Date	Editor	Changes Made
HL7 Informative Ballot	4/2014	Patti Aymond, Lizzie DeYoung, Timothy Grapes, Werner Joerg, John Roberts, and Brian Wilkens	Initial Draft.
HL7 Informative Ballot	8/2015	W. Joerg & Patti Aymond	Addressed comments from 5/2014 Informative Ballot.
OASIS Committee Note	5/2016	Patti Aymond	Addressed comments from 8/2015 Informative Ballot.