Description: Notesidebar                                                                                            

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.

 

Notices

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.

 

Table of Contents

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

 

 


1        Introduction

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

2        Scope – Scenarios and Use Cases

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        Background

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.


 

4        Transforms Spreadsheet

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”).

 


 

5        EDXL data structures

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

 

6        HL7 Data Structures

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

 

A14 - Pending Admit

Segments

Description

SEQ

DT

OPT

MSH

Message Header

 

 

Field Separator

1

ST

R

Encoding Characters

2

ST

R

Sending Application

3

HD

O

Sending Facility

4

HD

O

Namespace ID

4.1

IS

O

Universal ID

4.2

ST

C

Universal ID Type

4.3

ID

C

Receiving Application

5

HD

O

Receiving Facility

6

HD

O

Date/Time of Message

7

DTM

R

Security

8

ST

O

Message Type

9

MSG

R

Message Control ID

10

ST

R

Processing ID

11

PT

R

Version ID

12

VID

R

Sequence Number

13

NM

0

Continuation Pointer

14

ST

0

Accept Acknowledgment Type

15

ID

0

Application Acknowledgment Type

16

ID

0

Country Code

17

ID

0

Character Set

18

ID

0

Principal Language Of Message

19

CWE

0

Alternate Character Set Handling Scheme

20

ID

0

Message Profile Identifier

21

EI

0

Sending Responsible Organization

22

XON

0

Receiving Responsible Organization

23

XON

0

Sending Network Address

24

HD

0

Receiving Network Address

25

HD

0

[{ SFT }]

Software Segment

 

 

Software Vendor Organization

1

XON

R

Software Certified Version or Release Number

2

ST

R

Software Product Name

3

ST

R

Software Binary ID

4

ST

R

Software Product Information

5

TX

O

Software Install Date

6

DTM

O

[ UAC ]

User Authentication Credential

 

 

User Authentication Credential Type Code

1

CWE

R

User Authentication Credential 

2

ED

R

EVN

Event Type

 

 

Event Type Code

1

W

Recorded Date/Time

2

DTM

R

Date/Time Planned Event

3

DTM

O

Event Reason Code

4

CWE

O

Operator ID

5

XCN

O

Event Occurred

6

DTM

O

Event Facility

7

HD

O

PID

Patient Identification

 

 

Set ID - PID

1

SI

O

Patient ID

2

W

Patient Identifier List

3

CX

R

ID Number

3.1

ST

R

Identifier Check Digit

3.2

ST

O

Check Digit Scheme

3.3

ID

O

Assigning Authority

3.4

HD

C

Namespace ID

3.4.1

IS

O

Universal ID

3.4.2

ST

C

Universal ID Type

3.4.3

ID

C

Identifier Type Code

3.5

ID

R

Assigning Facility

3.6

HD

O

Effective Date

3.7

DT

O

Expiration Date

3.8

DT

O

Assigning Jurisdiction

3.9

CWE

C

Assigning Agency or Department

3.10

CWE

C

Security Check

3.11

ST

O

Security Check Scheme

3.12

ID

O

Alternate Patient ID - PID

4

W

Patient Name

5

XPN

R

Mother's Maiden Name

6

XPN

O

Date/Time of Birth

7

DTM

O

Administrative Sex

8

CWE

O

Patient Alias

9

W

Race

10

CWE

O

Patient Address

11

XAD

O

County Code

12

W

Phone Number - Home

13

XTN

B

Phone Number - Business

14

XTN

B

Primary Language

15

CWE

O

Marital Status

16

CWE

O

Religion

17

CWE

O

Patient Account Number

18

CX

O

SSN Number - Patient

19

W

Driver's License Number - Patient

20

W

Mother's Identifier

21

CX

O

Ethnic Group

22

CWE

O

Birth Place

23

ST

O

Multiple Birth Indicator

24

ID

O

Birth Order

25

NM

O

Citizenship

26

CWE

O

Veterans Military Status

27

CWE

O

Nationality

28

W

Patient Death Date and Time

29

DTM

O

Patient Death Indicator

30

ID

O

Identity Unknown Indicator

31

ID

O

Identity Reliability Code

32

CWE

O

Last Update Date/Time

33

DTM

O

Last Update Facility

34

HD

O

Species Code

35

CWE

C

Breed Code

36

CWE

C

Strain

37

ST

O

Production Class Code

38

CWE

O

Tribal Citizenship

39

CWE

O

Patient Telecommunication Information

40

XTN

O

[ PD1 ]

Additional Demographics

 

 

Living Dependency

1

CWE

O

Living Arrangement

2

CWE

O

Patient Primary Facility

3

XON

O

Patient Primary Care Provider Name & ID No.

4

W

Student Indicator

5

CWE

O

Handicap

6

CWE

O

Living Will Code

7

CWE

O

Organ Donor Code

8

CWE

O

Separate Bill

9

ID

O

Duplicate Patient

10

CX

O

Publicity Code

11

CWE

O

Protection Indicator

12

ID

B

Protection Indicator Effective Date

13

DT

B

Place of Worship

14

XON

O

Advance Directive Code

15

CWE

C

Immunization Registry Status

16

CWE

O

Immunization Registry Status Effective Date

17

DT

O

Publicity Code Effective Date

18

DT

O

Military Branch

19

CWE

O

Military Rank/Grade

20

CWE

O

Military Status

21

CWE

O

Advance Directive Last Verified Date

22

DT

O

[{ ARV }]

Accesss Restrictions

 

 

Set ID

1

SI

O

Access Restriction Action Code

2

CNE

R

Access Restriction Value

3

CWE

R

Access Restriction Reason

4

CWE

O

Special Access Restriction Instructions

5

ST

O

Access Restriction Date Range

6

DR

O

[{ ROL }]

Role (Person level providers with an ongoing relationship)

 

 

Role Instance ID

1

EI

C

Action Code

2

ID

R

Role-ROL

3

CWE

R

Role Person

4

XCN

R

Role Begin Date/Time

5

DTM

O

Role End Date/Time

6

DTM

O

Role Duration

7

CWE

O

Role Action Reason

8

CWE

O

Provider Type

9

CWE

O

Organization Unit Type

10

CWE

O

Office/Home Address/Birthplace

11

XAD

O

Phone

12

XTN

O

Person's Location

13

PL

O

Organization

14

XON

O

[{ NK1 }]

Next of Kin / Associated Parties

 

 

Set ID - NK1

1

SI

R

Name

2

XPN

O

Relationship

3

CWE

O

Address

4

XAD

O

Phone Number

5

XTN

B

Business Phone Number

6

XTN

B

Contact Role

7

CWE

O

Start Date

8

DT

O

End Date

9

DT

O

Next of Kin / Associated Parties Job Title

10

ST

O

Next of Kin / Associated Parties Job Code/Class

11

JCC

O

Next of Kin / Associated Parties Employee Number

12

CX

O

Organization Name - NK1

13

XON

O

Marital Status

14

CWE

O

Administrative Sex

15

CWE

O

Date/Time of Birth

16

DTM

O

Living Dependency

17

CWE

O

Ambulatory Status

18

CWE

O

Citizenship

19

CWE

O

Primary Language

20

CWE

O

Living Arrangement

21

CWE

O

Publicity Code

22

CWE

O

Protection Indicator

23

ID

O

Student Indicator

24

CWE

O

Religion

25

CWE

O

Mother's Maiden Name

26

XPN

O

Nationality

27

CWE

O

Ethnic Group

28

CWE

O

Contact Reason

29

CWE

O

Contact Person's Name

30

XPN

O

Contact Person's Telephone Number

31

XTN

B

Contact Person's Address

32

XAD

O

Next of Kin/Associated Party's Identifiers

33

CX

O

Job Status

34

CWE

O

Race

35

CWE

O

Handicap

36

CWE

O

Contact Person Social Security Number

37

ST

O

Next of Kin Birth Place

38

ST

O

VIP Indicator

39

CWE

O

Next of Kin Telecommunication Information

40

XTN

O

Contact Person's Telecommunication Information

41

XTN

O

PV1

Patient Visit

 

 

Set ID - PV1

1

SI

O

Patient Class

2

CWE

R

Assigned Patient Location

3

PL

O

Admission Type

4

CWE

O

Preadmit Number

5

CX

O

Prior Patient Location

6

PL

O

Attending Doctor

7

XCN

O

Referring Doctor

8

XCN

O

Consulting Doctor

9

XCN

B

Hospital Service

10

CWE

O

Temporary Location

11

PL

O

Preadmit Test Indicator

12

CWE

O

Re-admission Indicator

13

CWE

O

Admit Source

14

CWE

O

Ambulatory Status

15

CWE

O

VIP Indicator

16

CWE

O

Admitting Doctor

17

XCN

O

Patient Type

18

CWE

O

Visit Number

19

CX

O

ID Number

19.1

ST

R

Identifier Check Digit

19.2

ST

O

Check Digit Scheme

19.3

ID

O

Assigning Authority

19.4

HD

C

Identifier Type Code

19.5

ID

R

Assigning Facility

19.6

HD

O

Effective Date

19.7

DT

O

Expiration Date

19.8

DT

O

Assigning Jurisdiction

19.9

CWE

C

Assigning Agency or Department

19.10

CWE

C

Security Check

19.11

ST

O

Security Check Scheme

19.12

ID

O

Financial Class

20

FC

O

Charge Price Indicator

21

CWE

O

Courtesy Code

22

CWE

O

Credit Rating

23

CWE

O

Contract Code

24

CWE

O

Contract Effective Date

25

DT

O

Contract Amount

26

NM

O

Contract Period

27

NM

O

Interest Code

28

CWE

O

Transfer to Bad Debt Code

29

CWE

O

Transfer to Bad Debt Date

30

DT

O

Bad Debt Agency Code

31

CWE

O

Bad Debt Transfer Amount

32

NM

O

Bad Debt Recovery Amount

33

NM

O

Delete Account Indicator

34

CWE

O

Delete Account Date

35

DT

O

Discharge Disposition

36

CWE

O

Discharged to Location

37

DLD

O

Diet Type

38

CWE

O

Servicing Facility

39

CWE

O

Bed Status

40

W

Account Status

41

CWE

O

Pending Location

42

PL

O

Prior Temporary Location

43

PL

O

Admit Date/Time

44

DTM

O

Discharge Date/Time

45

DTM

O

Current Patient Balance

46

NM

O

Total Charges

47

NM

O

Total Adjustments

48

NM

O

Total Payments

49

NM

O

Alternate Visit ID

50

CX

O

Visit Indicator

51

CWE

O

Other Healthcare Provider

52

W

Service Episode Description

53

ST

O

Service Episode Identifier

54

CX

O

[ PV2 ]

Patient Visit - Additional Info.

 

 

Prior Pending Location

1

PL

C

Accommodation Code

2

CWE

O

Admit Reason

3

CWE

O

Transfer Reason

4

CWE

O

Patient Valuables

5

ST

O

Patient Valuables Location

6

ST

O

Visit User Code

7

CWE

O

Expected Admit Date/Time

8

DTM

O

Expected Discharge Date/Time

9

DTM

O

Estimated Length of Inpatient Stay

10

NM

O

Actual Length of Inpatient Stay

11

NM

O

Visit Description

12

ST

O

Referral Source Code

13

XCN

O

Previous Service Date

14

DT

O

Employment Illness Related Indicator

15

ID

O

Purge Status Code

16

CWE

O

Purge Status Date

17

DT

O

Special Program Code

18

CWE

O

Retention Indicator

19

ID

O

Expected Number of Insurance Plans

20

NM

O

Visit Publicity Code

21

CWE

O

Visit Protection Indicator

22

ID

B

Clinic Organization Name

23

XON

O

Patient Status Code

24

CWE

O

Visit Priority Code

25

CWE

O

Previous Treatment Date

26

DT

O

Expected Discharge Disposition

27

CWE

O

Signature on File Date

28

DT

O

First Similar Illness Date

29

DT

O

Patient Charge Adjustment Code

30

CWE

O

Recurring Service Code

31

CWE

O

Billing Media Code

32

ID

O

Expected Surgery Date and Time

33

DTM

O

Military Partnership Code

34

ID

O

Military Non-Availability Code

35

ID

O

Newborn Baby Indicator

36

ID

O

Baby Detained Indicator

37

ID

O

Mode of Arrival Code

38

CWE

O

Recreational Drug Use Code

39

CWE

O

Admission Level of Care Code

40

CWE

O

Precaution Code

41

CWE

O

Patient Condition Code

42

CWE

O

Living Will Code

43

CWE

O

Organ Donor Code

44

CWE

O

Advance Directive Code

45

CWE

C

Patient Status Effective Date

46

DT

O

Expected LOA Return Date/Time

47

DTM

C

Expected Pre-admission Testing Date/Time

48

DTM

O

Notify Clergy Code

49

CWE

O

Advance Directive Last Verified Date

50

DT

O

[{ ARV }]

Access Restrictions

 

 

Set ID

1

SI

O

Access Restriction Action Code

2

CNE

R

Access Restriction Value

3

CWE

R

Access Restriction Reason

4

CWE

O

Special Access Restriction Instructions

5

ST

O

Access Restriction Date Range

6

DR

O

[{ ROL }]

Role (Providers corresponding to the PV1 data)

 

 

Role Instance ID

1

EI

C

Action Code

2

ID

R

Role-ROL

3

CWE

R

Role Person

4

XCN

R

Role Begin Date/Time

5

DTM

O

Role End Date/Time

6

DTM

O

Role Duration

7

CWE

O

Role Action Reason

8

CWE

O

Provider Type

9

CWE

O

Organization Unit Type

10

CWE

O

Office/Home Address/Birthplace

11

XAD

O

11.6

Phone

12

XTN

O

Person's Location

13

PL

O

Organization

14

XON

O

[{ DB1 }]

Disability Information

 

 

Set ID - DB1

1

SI

R

Disabled Person Code

2

CWE

O

Disabled Person Identifier

3

CX

O

Disability Indicator

4

ID

O

Disability Start Date

5

DT

O

Disability End Date

6

DT

O

Disability Return to Work Date

7

DT

O

Disability Unable to Work Date

8

DT

O

[{ OBX }]

Observation/Result

 

 

Set ID - OBX

1

SI

O

Value Type

2

ID

C

Observation Identifier

3

CWE

R

Observation Sub-ID

4

ST

C

Observation Value

5

varies

C

Units

6

CWE

O

References Range

7

ST

O

Interpretation Codes

8

CWE

O

Probability

9

NM

O

Nature of Abnormal Test

10

ID

O

Observation Result Status

11

ID

R

Effective Date of Reference Range

12

DTM

O

User Defined Access Checks

13

ST

O

Date/Time of the Observation

14

DTM

O

Producer's ID

15

CWE

B

Responsible Observer

16

XCN

B

Observation Method

17

CWE

O

Equipment Instance Identifier

18

EI

B

Date/Time of the Analysis

19

DTM

O

Observation Site

20

CWE

O

Observation Instance Identifier

21

EI

O

Mood Code

22

CNE

C

Performing Organization Name

23

XON

B

Performing Organization Address

24

XAD

B

Performing Organization Medical Director

25

XCN

B

Patient Results Release Category

26

ID

O

[{ AL1 }]

Allergy Information

 

 

Set ID - AL1

1

SI

R

Allergen Type Code

2

CWE

O

Allergen Code/Mnemonic/Description

3

CWE

R

Allergy Severity Code

4

CWE

O

Allergy Reaction Code

5

ST

O

Identification Date

6

W

[{ DG1 }]

Diagnosis Information

 

 

Set ID - DG1

1

SI

R

Diagnosis Coding Method

2

W

Diagnosis Code - DG1

3

CWE

R

Diagnosis Description

4

W

Diagnosis Date/Time

5

DTM

O

Diagnosis Type

6

CWE

R

Major Diagnostic Category

7

W

Diagnostic Related Group

8

W

DRG Approval Indicator

9

W

DRG Grouper Review Code

10

W

Outlier Type

11

W

Outlier Days

12

W

Outlier Cost

13

W

Grouper Version And Type

14

W

Diagnosis Priority

15

NM

O

Diagnosing Clinician

16

XCN

O

Diagnosis Classification

17

CWE

O

Confidential Indicator

18

ID

O

Attestation Date/Time

19

DTM

O

Diagnosis Identifier

20

EI

C

Diagnosis Action Code

21

ID

C

Parent Diagnosis

22

EI

C

DRG CCL Value Code

23

CWE

O

DRG Grouping Usage

24

ID

O

DRG Diagnosis Determination Status

25

CWE

O

Present On Admission (POA) Indicator

26

CWE

O

[ DRG ]

Diagnosis Related Group

 

 

Diagnostic Related Group

1

CNE

O

DRG Assigned Date/Time

2

DTM

O

DRG Approval Indicator

3

ID

O

DRG Grouper Review Code

4

CWE

O

Outlier Type

5

CWE

O

Outlier Days

6

NM

O

Outlier Cost

7

CP

O

DRG Payor

8

CWE

O

Outlier Reimbursement

9

CP

O

Confidential Indicator

10

ID

O

DRG Transfer Type

11

CWE

O

Name of Coder

12

XPN

O

Grouper Status

13

CWE

O

PCCL Value Code

14

CWE

O

Effective Weight

15

NM

O

Monetary Amount

16

MO

O

Status Patient

17

CWE

O

Grouper Software Name

18

ST

O

Grouper Software Version

19

ST

O

Status Financial Calculation

20

CWE

O

Relative Discount/Surcharge

21

MO

O

Basic Charge

22

MO

O

Total Charge

23

MO

O

Discount/Surcharge

24

MO

O

Calculated Days

25

NM

O

Status Gender

26

CWE

O

Status Age

27

CWE

O

Status Length of Stay

28

CWE

O

Status Same Day Flag

29

CWE

O

Status Separation Mode

30

CWE