Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Version 1.1
Committee Specification Draft 02 /
Public Review Draft 02
07 August 2018
Specification URIs
This version:
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/csprd02/edxl-tep-v1.1-csprd02.doc (Authoritative)
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/csprd02/edxl-tep-v1.1-csprd02.html
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/csprd02/edxl-tep-v1.1-csprd02.pdf
Previous version:
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/cs01/edxl-tep-v1.1-cs01.doc (Authoritative)
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/cs01/edxl-tep-v1.1-cs01.html
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/cs01/edxl-tep-v1.1-cs01.pdf
Latest version:
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.doc (Authoritative)
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.html
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.pdf
Technical Committee:
Chair:
Elysa Jones (elysajones@yahoo.com), Individual
Editors:
Werner Joerg (wjoerg@netessence.com), Individual
Patti Iles Aymond (patti.aymond@iem.com), IEM
This specification is related to:
Declared XML namespace:
Abstract:
EDXL-TEP is an XML messaging standard primarily for exchange of emergency patient and tracking information from the point of patient encounter through definitive care admission or field release. TEP supports patient tracking across the Emergency Medical Services (EMS) care continuum, as well as hospital evacuations and patient transfers, providing real-time information to responders, Emergency Management, coordinating organizations and care facilities in the chain of care and transport.
Status:
This document was last revised or approved by the OASIS Emergency Management TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency#technical.
TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/emergency/.
This specification is provided under the RF on RAND Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/emergency/ipr.php).
Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.
Citation format:
When referencing this specification the following citation format should be used:
[EDXL-TEP-v1.1]
Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Version 1.1. Edited by Werner Joerg and Patti Iles Aymond. 07 August 2018. OASIS Committee Specification Draft 02 / Public Review Draft 02. http://docs.oasis-open.org/emergency/edxl-tep/v1.1/csprd02/edxl-tep-v1.1-csprd02.html. Latest version: http://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.html.
Notices
Copyright © OASIS Open 2018. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.
Table of Contents
1.3 Structure of the EDXL Tracking of Emergency Patients Specification
2 Design Principles & Concepts (non-normative)
3 EDXL Tracking of Emergency Patients
3.1 TEP Message Definition (non-normative)
3.2 Supporting Elements (non-normative)
3.2.2 Selecting values from lists
3.2.3.1 Community augmentation
3.2.3.5 Special application of Extension
3.3 Element Reference Model (non-normative)
3.4 Distribution of EDXL-TEP (non-normative)
3.4.1 EDXL Distribution Element (EDXL-DE)
3.4.1.1 Identifying MessageType
3.4.1.2 Identifying Message Sender
4.13 Glossary / List of Acronyms
Appendix B. XML Schema for EDXL-TEP
Appendix C. XML Schema for EDXL-Extensions
This specification is provided under the RF on RAND Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/emergency/ipr.php).
The ongoing goal of the Emergency Data eXchange Language (EDXL) project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved.
The current roster of EDXL Standards includes:
§ The Common Alerting Protocol v1.2 specification [CAP-1.2], with various dedicated profiles
§ The Distribution Element specification v2.0 [EDXL-DE 2.0]
§ The Hospital AVailability Exchange specification v1.0 [EDXL-HAVE]
§ The Resource Messaging specification v1.0 [EDXL-RM]
§ The Situation Reporting specification v1.0 [EDXL-SitRep]
The primary purpose of EDXL-TEP is an XML messaging standard for exchange of emergency patient and tracking information during patient encounter through admission or release. TEP supports patient tracking across the Emergency Medical Services (EMS) care continuum, as well as hospital evacuations and patient transfers, providing real-time information to responders, Emergency Management, coordinating organizations and care facilities in the chain of care and transport.
The TEP purpose is aimed at increased effectiveness of emergency medical management, patient tracking, and continued patient care capabilities during emergency care. TEP is driven by cross-profession practitioner needs (Practitioner Steering Group), and led by the National Association of State EMS Officials (NASEMSO). It also supports select goals of the HHS-Agency for Health and Research Quality (AHRQ), NDMS process and systems, and gaps identified by the Health Information Technology Standards Panel (HITSP).
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. CID creates and deploys Information resources such as standards, frameworks, tools, and technologies.
CID is organized into five program areas: Basic/Futures Research; Cyber Security; Knowledge Management Tools; Office for Interoperability and Compatibility (OIC); and Reconnaissance, Surveillance, and Investigative Technologies.
Following voice interoperability programs such as SAFECOM, the OIC’s interoperable messaging standards program was initiated as one of the President’s e-Gov initiatives in 2001. The OIC mission is to serve as the standards program within the Federal Government to facilitate local, tribal, state, and federal 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.
EDXL will accomplish this mission through the standardization of specific messages (XML messaging interfaces) which facilitate coordination and emergency communication between disparate software applications and systems - particularly when more than one profession or jurisdiction is involved.
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.
The OIC-sponsored PSG governance was formalized following publication of the EDXL Distribution Element. It plays a key role in the direction, prioritization, definition, and execution of the DHS-OIC program. The group is comprised of representatives of major emergency response associations and organizations, setting priorities and providing recommendations regarding messaging standards development as well as the other facets of the OIC-EDXL program.
A number of requests, requirements and detailed studies converged to drive the requirement for a standard data exchange for patient tracking across disparate jurisdictions, professions using the many systems in place today or planned. Figure 1 below provides a graphical depiction of various driving efforts and time-line.
· The Agency for Healthcare Research and Quality’s (AHRQ) “Recommendations for a National Mass Patient and Evacuee Movement, Regulating, and Tracking System”. [AHRQ Natl Patient / Evacuee Track Sys]
· Gaps and requirements identified by the Office of the National Coordinator (ONC) sponsored IS-04 Emergency Responder Emergency Health Record (ER-EHR) [ER-EHR] & Use Cases.
· The Health Information Technology Standards Panel (HITSP) ER-EHR Interoperability specification [ER-EHR Interoperability].
· As gaps were assigned to various agencies to address, the National Association of State EMS Officials (NASEMSO) submitted a formal request to DHS-S&T on behalf of the state and local practitioners, to facilitate the many stakeholders to a consensus-based requirement. This request was supported by HHS-AHRQ, ASPR and NDMS.
· Not depicted in Figure 1 are two major, multi-jurisdiction, multi-system live Patient Tracking exercises. Each of these exercises identified improvements which were integrated into the TEP standard as a result of actual disparate system data exchanges, observations and input from participating organizations. A detailed description of the exercises is contained in Section 3.4 “Exercises”.
These efforts documented and demonstrated the current lack of a standardized approach to Patient Tracking, as numerous disparate patients tracking software systems are used to track patients across jurisdiction and professional boundaries, but cannot share information without one-off manual processes.
The NASEMSO and other stakeholder organizations looked to the DHS-S&T OIC EDXL standards process, which has demonstrated success facilitating standards through Federally-sponsored cross-profession efforts in partnership with public Standards Development Organizations (SDO) and private industry. Utilizing the requests, requirements and detailed studies discussed above coupled with standard process and governance, the requirements and specification effort was initiated by these stakeholders and a TEP Steering Committee was formed to drive and draft scope, secure participation, and escalate decision-making.
The EDXL-TEP draft specification was developed based on explicitly defined requirements and messaging specification, which was submitted to the OASIS Emergency Management Technical Committee (EM-TC) to begin work on this international EDXL-TEP standard.
The TEP standard is intended to provide a standardized way for any existing or planned system to seamlessly share patient tracking information, fully realizing the potential of these numerous systems.
The EDXL-TEP standard will facilitate exchange of emergency patient and tracking data, providing “real-time” information to responders and care facilities across the EMS emergency medical care continuum. TEP is used from the point of patient encounter until patient release from care, or admission (“handoff”) to definitive care (such as a hospital). TEP is aimed at the increased effectiveness of emergency medical management, patient tracking, and preparation for emergency care, supporting local, day to day needs as well as mass care situations across jurisdictions.
Fig. 1 Patient Tracking Collaboration History
The EDXL-TEP standard document structure is defined using successively more detailed or constrained artifacts in the form of textual descriptions, diagrams, figures, tables and Appendices. The EDXL-TEP XML Schema is provided separately. The overall structure of the EDXL-TEP message is first represented in an Element Reference Model (ERM). The ERM is the foundation from which individual constraint schemas (individual situation report types) are defined.
The structure of the EDXL-TEP standard is defined in the following sections:
· Section 3.1 presents an extensive definition of a TEP message;
· Section 3.2 describes essential supporting elements in the EDXL Common Types collection, including the EDXL Extension mechanisms - ValueList and CommunityExtension;
· Section 3.3 presents the Element Reference Model (ERM) which shows the abstract structural relationships of the main components of EDXL-TEP;
· Section 3.4 discusses how the distribution requirements for EDXL-TEP messages are met through the EDXL-Distribution Element (DE);
· Sections 3.5 and 3.6 present a summary of the elements that make up a TEP message.
These sections together define the message structure, message element definitions, optionality and
cardinality.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
In addition, within this Specification, the keyword “CONDITIONAL” SHOULD be interpreted as potentially “REQUIRED” or “OPTIONAL” depending on the surrounding context. The term payload refers to some body of information contained in the distribution element. The term “REQUIRED” means that empty elements or NULL values are NOT allowed.
For increased precision, these terms are complemented with the inclusive interval notation [lb .. ub], where lb stands for lower bound (default 0) and ub stands for upper bound (default '*' - any > 1). E.g. [1..1] means REQUIRED, exactly once, [0..*] means OPTIONAL, any number of times.
[CAP-1.2] Common Alerting Protocol Version 1.2, J. Westfall, Editor. 01 July 2010. OASIS Standard. https://www.oasis-open.org/standards#capv1.2.
[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-HAVE] Emergency Data Exchange Language (EDXL) Hospital AVailablity Exchange, S. Dwarkanath, Editor. OASIS Standard 01 https://www.oasis-open.org/standards#edxlhave-v1.0, 1 November 2008.
[EDXL-RM] Emergency Data Exchange Language (EDXL) Resource Messaging P. Aymond, R. Brooks, T. Grapes, G. Ham, R. Iannella, K. Robinson, W. Joerg, and A. Triglia, Editors. OASIS Standard. V1.0. https://www.oasis-open.org/standards#edxlrm-v1.0, 1 November 2008.
[namespaces]
Namespaces in XML 1.0 (Third Edition), T. Bray, D. Hollander, A. Layman, R. Tobin, H. Thompson, Editors. W3C Recommendation, December 8, 2009, http://www.w3.org/TR/2009/REC-xml-names-20091208/. Latest version available at http://www.w3.org/TR/xml-names.
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Editor. BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
[xlink] XML Linking Language (XLink) Version 1.1, S. DeRose, E. Maler, D. Orchard, N. Walsh, Editors. W3C Recommendation, May 6, 2010, http://www.w3.org/TR/2010/REC-xlink11-20100506/. Latest version available at http://www.w3.org/TR/xlink11/.
[XML 1.0] XML 1.0 Recommendation, T. Bray, J. Paoli, M. Sperberg-McQueen, Editors. W3C Recommendation, February 10, 1998, http://www.w3.org/TR/1998/REC-xml-19980210. Latest version available at http://www.w3.org/TR/REC-xml.
[XML Schema] XML Schema Part 2: Datatypes Second Edition, P. Biron, A. Malhotra, Editors. W3C Recommendation, October 28, 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Latest version available at http://www.w3.org/TR/xmlschema-2/.
[AHRQ Natl Patient / Evacuee Track Sys]
Recommendations for a National Mass Patient and Evacuee Movement, Regulating, and Tracking System, T. Rick, P. Biddinger, R. Zane, A. Hassol, and L. Savitz, Editors. Health and Human Services (HHS) Agency for Healthcare Research and Quality’s (AHRQ), January 2001, http://archive.ahrq.gov/prep/natlsystem/natlsys.pdf.
[EDXL-CIQ] Emergency Data Exchange Language Customer Information Quality, Committee Specification Draft, W. Joerg, J. Waters, and D. McGarry, Editors. OASIS, September 2011, http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/csd02/.
[EDXL-CT] Emergency Data Exchange Language Common Types, Committee Specification Draft, W. Joerg, R. Brooks, J. Waters, and D. McGarry, Editors. OASIS, November, 2011, http://docs.oasis-open.org/emergency/edxl-ct/v1.0/csd02/.
[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-EXT] EDXL Extension. OASIS https://tools.oasis-open.org/version-control/browse/wsvn/emergency/HAVE/rim/edxl-ext-v1.0.xsd.
[EDXL-GSF] Emergency Data Exchange Language GML Simple Features, Committee Specification Draft, W. Joerg and L. Leinenweber, Editors. OASIS, September 2011, http://docs.oasis-open.org/emergency/edxl-gsf/v1.0/csd01/.
[EDXL-SitRep] Emergency Data Exchange Language Situation Reporting (EDXL-SitRep) Version 1.0, Committee Specification 01, R. Brooks and T. Grapes, Editors. OASIS, 11 April 2013, http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/.
[ER-EHR] IS-04 Emergency Responder Emergency Health Record (ER-EHR), http://www.hitsp.org/InteroperabilitySet_Details.aspx?MasterIS=true&InteroperabilityId=51&PrefixAlpha=1&APrefix=IS&PrefixNumeric=04.
[ER-EHR Interoperability]
IS-04 ER-EHR Interoperability specification, http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=1&PrefixNumeric=04.
[NEMSIS v2.2.1]
National Emergency Medical System Information System (NEMSIS) v2.2.1, http://nemsis.org/v2/index.html.
[NENA-Next Generation 911]
National Emergency Number Association (NENA) – Next Generation 911, http://www.nena.org/?NG911_Project.
[NIEM] National Information Exchange Model (NIEM). www.niem.gov.
Below are some of the guiding principles behind the development of EDXL-TEP:
· Provide a standard message format for the Tracking of Emergency Patients data exchange standard
· Separation of EDXL-TEP message structure from routing header structure
· Facilitate any mechanisms or techniques for routing and movement of TEP messages, such as point to point, use of an open or proprietary message broker, publish / subscribe, etc.
· Enable dissemination of messages based on geographic delivery area
· Use and reuse of data content and models developed by other initiatives
· Business process-driven specific messaging needs across emergency professions
· Design for the basic needs of two primary systems categories:
o Those which require and utilize minimal data needed only to track patients’ status and physical location and movement (e.g. leaning toward a “Federal Express” package tracking model).
o Those which require additional optional data needed to understand more about a patient’s condition and care.
· Supporting everyday events and incident preparedness, as well as disasters
· Facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services
The initial requirements submitted to the Technical Committee by the DHS-OIC sponsored EDXL Standards Working Group (SWG) described in Section 1.2 can be reviewed at: https://www.oasis-open.org/committees/document.php?document_id=38215.
Referenced within the specification document, the Project Initiation Document (PID) contains the effort purpose, objectives and scope: https://www.oasis-open.org/committees/document.php?document_id=38228.
Notes:
- The following examples of usage scenarios were used as a basis for development of the practitioner requirements and messaging specification document which was submitted to OASIS. These scenarios are very basic, high-level and non-normative; not intended to be exhaustive or to fully reflect actual practices. Then follows a description of live patient movement exercises used as POC and pilots for the EDXL-TEP draft standard.
- These examples show that TEP relies on some sort of “mobile tracking” (i.e. connectivity from the field, incident scene, transportation vehicle etc.). It’s the only way a TEP message can be utilized as designed and as exercised in the field to date. This does not imply that TEP supports continuous GPS tracking where frequent messages, containing e.g. an ambulance location, are “pulsed out” to track its movement. The actual requirement is that a TEP message be sent whenever a change to core TEP data occurs (like patient condition, treatment, transport etc.).
![]() |
![]() |
![]() |
The draft TEP specification has been successfully piloted in two major, multi-jurisdiction, multi-system live Patient Tracking exercises, and demonstrated during the 2012 Integrated Medical, Public Health, Preparedness and Response Training Summit. These exercises validated scenarios, use cases and data requirements, and the applicability and value of the EDXL standards approach for patient tracking across locations, organizations, jurisdictions, and disparate implemented systems. Each exercise identified improvements which were incorporated into the practitioner requirements and draft specification submitted to OASIS.
u 2010 Tennessee National Disaster Medical System (NDMS) live Patient Movement Exercise & draft EDXL-TEP data exchange POC for Patient Tracking
The 2010 live patient movement exercise tracked nearly 100 live volunteer patients between the states of Maryland and Tennessee with TEP interoperability implemented among one Federal (HHS), two states and one local system. The results were used to enhance the TEP specification prior to submission to the SDO. Attributes of the exercise included:
a) Tracking of virtual patient movement from Baltimore, MD to Tennessee Patient Reception Area (PRA), followed by live volunteer patient movement from Tennessee PRA to multiple local hospitals.
b) Participating State Systems: State of Tennessee, and Memphis TN locality (2 systems, multiple independent organization implementations), State of Maryland.
c) Participating Federal Systems: Joint Patient Assessment and Tracking System(JPATS)
The following provides a high-level description how the EDXL-TEP data exchange
was utilized during the 2010 Tennessee National Disaster Medical System (NDMS)
live Patient Movement Exercise. In each instance, a TEP message for each
patient was sent/received instantaneously as patient or location data was
updated in the participating system.
The Maryland Institute for EMS Systems (MIEMSS) first utilized their HC Standard system (by GER) to identify, tag, scan, and transport each patient (100 in all) to NDMS DMAT at BWI Thurgood Marshall Airport
◦ TEP message sent from HC Standard to JPATS system
Patients were loaded to aircraft by NDMS personnel and flight departed from BWI Thurgood Marshall Airport.
◦ TEP update messages sent from JPATS back to HC standard, as well as to each of the two Tennessee systems.
Aircraft lands at Memphis, TNPRA and off loads patients to triage area.
◦ Recipient agency using DM Solutions system sends TEP update messages to all other systems mentioned
◦ Other TEP messages sent as patient care or treatment information is updated
Each patient is loaded on-board an ambulance, each departing for one of three local Memphis NDMS hospitals.
◦ DM Solutions sends TEP update messages (departure and destination information) to all systems, as well as to each destination hospital system
Each patient arrives at one of several local hospitals
◦ As patient info is updated, or as each patient arrives, receiving hospital system scans patient arrival and TEP update message send to all previous systems in the chain
u 2011 National Disaster Medical System (NDMS) Patient Movement Exercise & draft EDXL-TEP data exchange pilot for Patient Tracking
In 2011 five states within the National Level Exercise (NLE) utilized the improved TEP specification to track patient movement in and between the states of Missouri, Louisiana, Tennessee, Wisconsin, and Mississippi, with TEP interoperability enabled between four current tracking systems. Attributes of the exercise included:
a) Tracking of virtual patient movement from Patient Reception Area (PRA) to multiple local hospitals.
b) Participating State Systems: State of Tennessee, and Memphis TN locality (2 systems, multiple independent organization implementations), State of Maryland, Louisiana Region 6.
u 2012 Integrated Medical, Public Health, Preparedness and Response Training Summit EDXL-TEP demonstration
a) Tracking of live volunteer patients as they entered the assembly hall, in parallel with panel presentation of each system participant and the EDXL-TEP approach.
b) Participating State Systems: State of Tennessee, Memphis TN locality, State of Maryland, State of Louisiana Region 6.
c) Participating Federal Systems: Joint Patient Assessment and Tracking System (JPATS).
Section 3 of this Standard is normative unless otherwise stated. If any differences are found between any XML schema and its associated model, diagram, table or other artifact or text, then the XML schema MUST always take precedence and the other artifact(s) MUST be changed to match the XML schema.
Note: Please report any such errors to OASIS.
The TEP message is a single EDXL message that is intended to facilitate the pro-active sharing of EMS Provider, Patient Location, Incident, Patient Demographic, and Patient Care information as warranted to provide better patient care and preparation by facilities that will eventually provide ongoing and post-emergency care. This message addresses TEP requirements in a “data-driven” mode. Users may create or update data based on key events in the field. Any change will be captured and then shared via the TEP messaging standard according to local standard operating procedures and or implementation decisions. A TEP message may be sent if one and only one element is changed, or if a group of elements changes and are sent in compliance with the standard.
Typical actors:
- Senders EMS Providers, ED, Intermediate Care Facilities, Federally deployed care providers (NDMS, National Guard, etc.), "forwarders" of this information to others.
- Recipients: EMS Providers, Emergency Department, Intermediate Care Facilities, Hospitals, Emergency Dispatch, Emergency Operations Center, Incident Command Center, Emergency Management (other), Law Enforcement, Federally deployed care providers (NDMS, National Guard, etc.),
Supporting Element Types borrow re-usable elements from the EDXL Common Types (ct:) that apply to and support multiple areas of the TEP 1.0 messages, such as Location, PatientContact etc.. For instance incidentLocation relies on ct:EDXLLocationType, which consists of either EDXLGeoLocation for geographical information or EDXLGeoPoliticalLocation for geopolitical information. EDXLGeoLocation is of type edxl-gsf:EDXLGeoLocationType and EDXLGeoPoliticalLocation is of type ct:EDXLGeoPoliticalLocationType. This latter type consists of either a GeoCode (of type ct:ValueListType) or an Address (of type edxl-ciq:xAL:AddressType).
The following elements are used in this specification and can be found at the locations cited in the non-normative references in Section 1.6.
Supporting Element/Type |
Defined In |
ct:EDXLDateTimeType |
[EDXL-CT] 2.2.1 Simple Types |
ct:EDXLStringType |
[EDXL-CT] 2.2.1 Simple Types |
ct:PercentageType |
[EDXL-CT] 2.2.1 Simple Types |
ct:ValueListURIType |
[EDXL-CT] 2.2.1 Simple Types |
ct:ValueType |
[EDXL-CT] 2.2.1 Simple Types |
ct:DegreesCType |
[EDXL-CT] 2.2.1 Simple Types |
ct:EstimateType |
[EDXL-CT] 2.2.1 Simple Types |
ct:ValueListType |
[EDXL-CT] 2.2.2 Complex Types |
ct:ValueKeyType |
[EDXL-CT] 2.2.2 Complex Types |
ct:PersonDetailsType |
[EDXL-CT] 2.2.2 Complex Types |
ct:EDXLGeoPoliticalLocationType |
[EDXL-CT] 2.2.2 Complex Types |
ct:EDXLLocationType |
[EDXL-CT] 2.2.2 Complex Types |
gsf:EDXLGeoLocationType |
[EDXL-GSF] 3.1.1 EDXL GML Simple Features Elements and Types |
ct:ValueListURI |
[EDXL-CT] 2.2.3 Top Level Elements |
xal:addressType |
[EDXL-CIQ] xal:addressType |
ext:ExtensionType |
[EDXL-EXT] |
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. This structure has several advantages: (a) it provides flexibility for local communities to use community-defined terms and vocabulary; (b) it allows for the external maintenance of local or standardized lists; and (c) it avoids the problems inherent in attempting to constantly update hard-coded enumerations in a specification.
An existing vetted list SHOULD be referenced for defaults, but users could also reference their own value list .
The schema for ct:ValueListType is defined as
<xs:complexType name="ValueListType">
<xs:sequence>
<xs:element ref="ct:ValueListURI" minOccurs="1" maxOccurs="1"/>
<xs:element ref="ct:Value" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
and its application to the XML description of an element elementName of type ct:ValueListType would be:
<elementName>
<ct:ValueListURI>valueListURI</ct:ValueListURI>
<ct:Value>value_1</ct:Value>
…
<ct:Value>value_n</ct:Value>
</elementName>
In the Data Dictionary we describe examples of elements of type ct:ValueListType by listing value assignments to valueListURI and value_1, …, value_n.
So for instance an example for “specialMedicalNeeds” is described by
- valueListURI = urn:myagency:gov:ahrq:specialMedicalNeeds and
- value_1 = Ventilator
- value_2 = Oxygen
which stands for
<specialMedicalNeeds>
<ct:ValueListURI>urn:myagency:gov:ahrq:specialMedicalNeeds</ct:ValueListURI>
<ct:Value>Ventilator</ct:Value>
<ct:Value>Oxygen</ct:Value>
</specialMedicalNeeds>
This example contains two special needs, one whose value is “Ventilator” and one whose value is “Oxygen”. These are notional needs created for this example. The needs are identified as values from a list whose unique Uniform Reference Identifier (URI) is “urn:myagency:gov:ahrq:specialMedicalNeeds”.
A note about ValueList: the multiplicity of ValueList can be a source for confusion. Typically, 1 is the maximum number of occurrences of ValueList. This means that at most one such list MAY occur for a given element; this does not preclude the user from selecting multiple entries from that list (maxOccurs = “unbounded”).
The schema for ValueKeyType is defined as
<xs:complexType name="ValueKeyType">
<xs:sequence>
<xs:element ref="ct:ValueListURI" minOccurs="1" maxOccurs="1"/>
<xs:element ref="ct:Value" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
and its application to the XML description of an element elementName of type ct:ValueKeyType would be:
<elementName>
<ct:ValueListURI>valueListURI</ct:ValueListURI>
<ct:Value>value</ct:Value>
</elementName>
This example uses a published list of values and definitions and selects one specific entry to describe the eyeColor of a patient:
- valueListURI = urn:myagency:gov:OMG:eyeColors
- value = Green
which stands for
<eyeColor>
<ct:ValueListURI>urn:myagency:gov:OMG:eyeColors</ct:ValueListURI>
<ct:Value>Green</ct:Value>
</eyeColor>
Following the approach in ValueList, we'd point ValueListURI to some other list to make a different selection of eye colors available.
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 TEP.
2. List augmentation: community adds new values (enumerations) to the default set of values in the standard. Example: adding FlightRisk value to the 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.
For more details about EDXL Extensions and usage guidance, refer to the white paper [EDXL-EXT] referenced in section 1.6 Non-Normative References.
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.
Note that this mechanism SHOULD be used only for required elements – if an element is optional, it could be completely replaced by any community extension, with its own name and structure.
Note also that for each example we assume that the schema contains the following element to allow for adding extensions:
<xsd:element name="extension"
type="ext:ExtensionType" minOccurs="0" maxOccurs="unbounded"/>
The following example illustrates the use of ExtensionType to build a community specific “layer” .
Example: adding an “earthquake layer” to an EDXL standard
- XML invocation:
<extension>
<community>http://www.myCommunity.org/layers/earthquake/</community>
<id>earthquakeLayer</id>
<parameter>
<nameURI>http://example/layers/earthquake/Magnitude</nameURI>
<value uom=”http://example/layers/earthquake/RichterScale”>5.3</value>
</parameter>
<parameter>
<nameURI>http://example/layers/earthquake/EventTime</nameURI>
<value>2010-08-30T23:25:40+00:00</value>
</parameter>
<parameter>
<nameURI>http://example/layers/earthquake/Depth</nameURI>
<value
uom=”http://qudt.org/vocab/unit/MileInternational>38.7</value>
</parameter>
</extension>
If the list is defined as a ValueList or a ValueKey, then use the corresponding mechanisms described above to point to revised lists. If the list is defined as an enumeration, then the augmentation can be achieved with the Extension mechanism.
The following example illustrates the use of ExtensionType to add community specific enumeration(s).
Example: adding “ReleasedForRehab” and “PostRehabRecidivismt” o PatientCurrentDispositionDefaultValues enumeration in TEP
- schema particulars:
<xsd:simpleType
name="PatientCurrentDispositionDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration value="Discharged "/>
<xsd:enumeration value="Transferred"/>
<xsd:enumeration value="Deceased"/>
<xsd:enumeration
value="NoTreatmentRequired"/>
<xsd:enumeration value="RefusedCare"/>
<xsd:enumeration value="TreatedAndReleased"/>
<xsd:enumeration value="TreatedAndTransferredCare"/>
<xsd:enumeration
value="TreatedAndTransported"/>
<xsd:enumeration value="Admitted"/>
<xsd:enumeration
value="TreatedAndTransportedToHospital"/>
<xsd:enumeration value="Pending-Ongoing"/>
<xsd:enumeration value="ExtensionValue"/>
</xsd:restriction>
</xsd:simpleType>
and some URI (e.g. www.patientDispositionExtension.org), enumerates the additional values:
<xsd:restriction base=”ct:EDXLStringType”>
<xsd:enumeration value=”ReleasedForRehab”/>
<xsd:enumeration value=”PostRehabRecidivism”/>
</xsd:restriction>
- XML invocations:
<patientCurrentDisposition>ExtensionValue</patientCurrentDisposition>
...
<extension>
<community>http://www.patientDispositionExtension.org</community>
<id>specialDispositionRehab</id>
<parameter>
<nameURI xPath=”/.../patientCurrentDisposition”>
http://example/US/EMS/dispositionCodes
</nameURI>
<value>ReleasedForRehab</value>
</parameter>
</extension>
If the list is defined as a ValueList or a ValueKey, then use the corresponding mechanisms described above to point to a replacement list. If the list is defined as an enumeration, then the replacement can be achieved with the Extension mechanism.
Example: the default triage codes are {“Red", "Yellow", "Green, "Blue", "Black" and "ExtensionValue"}. To allow for the use of “Purple” from a different list of values, the TEP message would look like:
<TEPMessage>
<extension>
<community>http://example/US/EMS</community>
<id>layer2</id>
<parameter>
<nameURI xPath="./patient/patientEncounter/patientCare/triageStatus"> http://example/US/EMS/triageCodes
<value>Purple</value>
</parameter>
</extension>
...
<patient>
<patientEncounter>
<patientCare>
<triageStatus>ExtensionValue</triageStatus>
</patientCare>
</patientEncounter>
</patient>
</TEPMessage>
If the list is defined as a ValueList or a ValueKey, then use the corresponding mechanisms described above to point to list redefinitions. If the list is defined as an enumeration, then the redefinition can be achieved with the Extension mechanism. Note that list redefinition may pose significant risk to interoperability and therefore, whether the list is completely redefined or only partially, best practices suggest that the extension mechanism MUST be used, to signal that risk.
Example: if one or more triage values are the same but have different meaning, then we use a redefined list with Extension:
<TEPMessage>
<extension>
<community>http://example/US/EMS</community>
<id>layer2</id>
<parameter>
<nameURI xPath=”./patient/patientEncounter/patientCare/triageStatus”>
http://example/US/EMS/triageCodes
<value>Black</value>
</parameter>
</extension>
…
<patient>
<patientEncounter>
<patientCare>
<triageStatus>ExtensionValue</triageStatus>
</patientCare>
</patientEncounter>
</patient>
</TEPMessage>
Extensions can be used for other tasks such as translating TEP message structures to/from HL 7 structures. Here are two examples that address the TEP/HL7 translation problem for HL7 v2 and HL7 v3.
- HL7 v2:
<TEPMessage>
<extension>
<community>TEP:v10: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:v10: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>
Figure 2 (below) shows the EDXL–TEP Element Reference Model (ERM). The purpose of the ERM is to define the TEP structure and the relationships between the main entities and their elements. Using the Unified Modeling Language as a means to illustrate the relationships, the ERM is not strictly normative. It is important that the ERM is not used as an implementation model. The exact semantics and structure are captured in the subsequent sections including the Data Dictionary, and the xsd schemas.
The primary purpose of the Emergency Data Exchange Language Tracking of Emergency Patients (EDXL-TEP) Specification is to provide an XML messaging standard for exchange of emergency patient and tracking information during patient encounter through admission or release, tracking across the EMS emergency medical care continuum, as well as hospital evacuations and patient transfers. These EDXL-TEP messages are specifically designed as payloads of an EDXL-DE. Together EDXL-DE and EDXL-TEP are intended to providing real-time information to responders, Emergency Management, coordinating organizations and care facilities in the chain of care and transport.. As set forth in Design Principles, routing and distribution information is found only in the EDXL-DE and not in the EDXL-TEP.
While the EDXL-TEP is designed to be an EDXL-DE payload, other routing mechanisms may be used to distribute EDXL-TEP content if the message meta-data is provided in the same form or if the sender specifies specific recipients of the payload. Both the [EDXL-DE 1.0] standard, referenced in section 1.5 Normative References, and the [EDXL-DE 2.0] committee specification, referenced in section 1.6 Non-Normative References, meet the EDXL-TEP routing and distribution requirements.
EDXL-TEP is designed to be routed using the DE. If other routing/transport mechanisms are being used, they MUST support at least the meta-data used by the DE, as described henceforth (non-normative).
EDXL Distribution Element (EDXL-DE) V 2.0 was approved as an OASIS standard in … 2012. The EDXL-DE provides a flexible message-distribution framework for data sharing among emergency information systems using XML. The EDXL-DE may be used over any data transmission system, including, but not limited to, the SOAP HTTP binding.
The primary purpose of the Distribution Element is to facilitate the routing of emergency messages to recipients. The Distribution Element may be thought of as a container. It provides the information to route "payload" message sets by including key routing information such as distribution type, geography, incident, and sender/recipient IDs. Messages may be distributed to specific recipients, to recipients in a geographic area, or based on codes such as agency type (police, fire, etc.).
The following subsections describe practitioner requirements which are met through the EDXL-Distribution Element (DE). The listed requirement type and numbers refer to the Practitioners' requirements document “EDXL-TEP-Rqmts&draftMessagingSpecFinalV2.2_05-05-2010.pdf”.
The Requirement for identifying the “Message Type” of the EDXL-TEP is handled by the <DistributionKind> element of EDXL-DE v2.0.
The <DistributionKind> element defines the function of the message. It presents a choice between a user-defined value or a default value, but only a single value MAY be specified:
<DistributionKind>
<ct:ValueListURI>ValueListURI</ct:ValueListURI>
<ct:Value>value</ct:Value>
</DistributionKind>
If the default value list is used (”urn:oasis;names:tc:emergency:EDXL:DE2.0:Defaults:StatusType”) the functional name for the EDXL-TEP “Message Type” takes the form of an XML enumeration where the value MUST be one of:
§ Report - New information regarding an incident or activity.
§ Update - Updated information superseding a previous message.
§ Cancel - A cancellation or revocation of a previous message.
§ Request - A request for resources, information or action.
§ Response - A response to a previous request.
§ Ack - Acknowledgment of receipt of an earlier message.
§ Error - Rejection of an earlier message (for technical reasons).
It is important to note that identifying a text message as a “Request” for a TEP Message is handled by the EDXL <DistributionKind> element. More generally: where an existing EDXL-DE element meets a stated requirement, that element is not duplicated or referred to in the body of a TEP Message. The assumption and rule is that the EDXL-DE or equivalent will be used to route TEP messages, and therefore these requirements are satisfied by the DE.
This capability supports functional requirements #6, 11 and information requirement #2.
The Requirement for identifying the “Message Sender” of the EDXL-TEP is handled by one or two elements of EDXL-DE v2.0.The EDXL-DE v2.0 <SenderID> or an element with the identical definition and properties MUST be present in the EDXL-DE or other routing mechanism used to distribute an EDXL-TEP message. The <SenderRole> or an element with the identical definition and properties MAY be present.
<SenderRole> is expressed in an XML ValueList and Value.
§ The list and associated value(s) is in the form:
<SenderRole>
<ct:ValueListURI>valueListURI</ValueListURI>
<ct:Value>value</Value>
</SenderRole>
§ Where the content of <ValueListURI> is the Uniform Resource Identifier of a published list of values and definitions, and the content of <Value> is a string (which MAY represent a number) denoting the value itself.
Multiple instances of the <Value>, MAY occur with a single <ValueListURI> within the <SenderRole> container.
SenderID supports functional requirement #6 and information requirements #3, 21;
SenderRole supports functional requirement #6 and information requirements #3;.
The EDXL-DE v2.0 <DateTimeSent> element is used to established the date and time the EDXL-DE package contained the EDXL-TEP message is sent.
§ [XML Schema] 3.2.7 dateTime elements, referenced in section 1.5 Normative References, are represented consistent with previous EDXL standards (24-hour clock):
§ The date and time is represented in [XML Schema] 3.2.7 dateTime format (e. g., "2008-06-11T16:49:00-07:00" for 11 June 2008 at 16:49 PDT), referenced in section 1.5 Normative References.
Alphabetic time zone designators such as “Z” MUST NOT be used. The time zone for UTC MUST be represented as “-00:00” or “+00:00
This capability supports functional requirement #6 and information requirement #4.
The <ContentObject> construct in EDXL-DE 2.0 allows to carry multiple EDXL messages in the same DE message: each <ContentObject> MUST be well-formed <ContentXML> or <OtherContent>. EDXL-TEP is designed to be well-formed XML for routing, using EDXL-DE.
A digital version of a signature MAY optionally be included to provide the authority that authenticates a particular TEP message. A digital signature MUST be provided in the form of a graphic image carried by the EDXL-DE message header as separate content object.
Additional documents such as photographs, fingerprints or health records may be attached to a TEP message, using the <ContentObject> construct of EDXL-DE, or other routing / transport mechanism with similar capability. Security or encryption needs for attachments are to be handled at the DE level.
This capability supports information requirement #5
A TEP message consists of a message identifier (messageID - required) that uniquely identifies the message, a system identifier (systemID – optional) that identifies the source of the information, and a group of elements (patient – required) that uniquely identifies and describes the patient in terms of
§ personal identifying information such as gender, race, date of birth, hair color, etc.
§ communication / contact information such as spoken languages, family unification code, ..
§ special needs regarding transportation, medical attention, barriers to care, allergies, ..
§ situation information such as incident, location, time, ..
§ healthcare provider information such as kind, name, jurisdiction, ..
§ patient encounter information such as location, time, triage, care, ..
These elements are detailed further in Figure 2 and in the Data Dictionary (Section 4).
Figure 2 EDXL–TEP Element Reference Model (ERM)
The data dictionary is intended to provide detailed definition of each element contained in the EDXL-TEP standard. Where discrepancies may exist between this dictionary, the Element Reference Model (ERM), and the normative schema, the normative schema SHALL take precedence.
Element / ElementType– Name of the element or element type.
Type – Type or format of the element.
Usage – Optionality and Cardinality (the latter is for Element only).
If no optionality specified, then the element is “OPTIONAL”.
If no cardinality specified, the element “MUST be used once and only once”
Definition – Definition of the element / type.
Comments – Additional comments or examples to add clarity.
Constraints – Limits imposed on the element. Also notes the container or “parent” to which the element belongs.
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.
Sub-elements – List of references to elements that are part of this element
Used In – Source of the requirement or usage of the element.
Requirements Supported – A code representing and referring to each requirement contained in the original submission from the practitioner process to OASIS. EACH general, functional or information requirement is accounted for by one or more elements in the data dictionary, and/or by relationships in the message structure, one or more business rules, or through the overall standard (e.g. for general and functional requirements). Key:
gReq# - “General” requirement number.
fReq# - “Functional” requirement number.
iReq# - “Information” requirement number.
Namespace prefixes: we use the following prefixes for namespace scoping of elements and types
xsd = "http://www.w3.org/2001/XMLSchema"
predefined types in XMLSchema space [XML Schema] referenced in section 1.5 Normative References
ct = "urn:oasis:names:tc:emergency:edxl:ct:1.0"
common types in EDXL space [EDXL-CT] referenced in section 1.6 Non-Normative References
ext = "urn:oasis:names:tc:emergency:edxl:extension:1.0"
extension mechanism for EDXL Standards [EDXL-EXT] referenced in section 1.6 Non-Normative References
xal = "urn:oasis:names:tc:emergency:edxl:ciq:1.0:xal"
elements / types in EDXL-CIQ-xAL (extensible Address Language) space [EDXL-CIQ] referenced in section 1.6 Non-Normative References
tep = "urn:oasis:names:tc:emergency:EDXL:TEP:1.0"
elements / types in EDXL-TEP space
tep-ct = "urn:oasis:names:tc:emergency:EDXL:TEP:Defaults:1.0"
common types in EDXL-TEP space
For an explanation of examples for ValueListType and ValueKeyType, see sections 3.2.2 and 3.2.3.
Naming convention: in order to mark a clear distinction between elements and types, names of elements MUST NOT contain the string “Type” and MUST be formatted in camel-type (lower case leading alpha character); types are to be terminated by the string “Type” and MUST be formatted in Pascal-type (upper case leading alpha character). Acronyms that are part of a type/element identifier MUST preserve their all upper case format.
The following list of elements / information requirements are addressed through an OASIS EDXL-Distribution Element (DE) routing header (See Section 3.4 of this document for an explanation of each), which is used for routing and distribution of Emergency Patient information as well as other EDXL and non-EDXL payloads. EDXL-TEP is designed as a payload requiring use of a routing header, and specifically designed for use with an EDXL-Distribution Element (DE). The EDXL-DE is the required routing/distribution header for EDXL-TEP unless an alternative routing header is available which meets all requirements of the EDXL-TEP as specified in this section, and includes each element required of the EDXL-DE specification. Both the [EDXL-DE 1.0], referenced in section 1.5 Normative References, standard and the [EDXL-DE 2.0] committee specification, referenced in section 1.6 Non-Normative References, meet the EDXL-TEP routing and distribution requirements.
EDXL-TEP Requirement |
EDXL-DE Element(s) |
MessageType |
DistributionKind |
MessageSender |
SenderID and SenderRole |
SentDateTime |
DateTimeSent |
Signature |
OtherContent containers |
Attachments |
ContentXML and OtherContent containers |
Type |
xsd:complexType |
Usage |
REQUIRED; MUST be used once and only once |
Definition |
Group of elements used to uniquely identify a TEP message and its source. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- messageID [1..1]: ct:EDXLStringType - systemID [0..1]: ct:EDXLStringType - patient [1..1]: tep:PatientType - extension [0..*]: ext:ExtensionType |
Used In |
EDXL-TEP |
Requirements Supported |
|
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED; MUST be used once and only once [1..1] |
Definition |
Each TEP message contains an identifier that uniquely identifies the message |
Comments |
1. The EDXL Distribution Element contains the "Distribution ID", which identifies the "container" for the distribution message information. 2. EDXL-RM and EDXL-SitRep also contain a messageID element for the same purpose. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
|
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL; MAY be used once and only once [0..1] |
Definition |
A unique system id, or login credentials of person entering TEP data, used to identify source of the information |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
|
Element |
|
Type |
tep: PatientType |
Usage |
REQUIRED; MUST be used once and only once [1..1] |
Definition |
Group of elements used to uniquely describe the patient. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
|
ElementType |
|
Type |
xsd:complexType |
Definition |
Group of elements associated with the person that has been encountered and determined or suspected to be a patient. Used to uniquely identify and describe the person. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- patientID [1..*]: tep:PatientIDType - gender [1..1]: tep:GenderDefaultValues - patientAge [1..1]: tep:PatientAgeType - 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 - healthCareProvider [1..1]: tep:HealthCareProviderType - patientEncounter [1..1]: tep:PatientEncounterType
|
Used In |
|
Requirements Supported |
|
Element |
|
Type |
tep: PatientIDType |
Usage |
REQUIRED; MUST be used at least once [1..*] |
Definition |
Used to uniquely identify the patient. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
|
Element |
|
Type |
tep: GenderDefaultValues |
Usage |
REQUIRED; MUST be used once and only once [1..1] |
Definition |
The patient gender |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References |
Constraints |
|
Valid Values / Examples |
Male, Female, … |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
ElementType |
|
Type |
xsd:enumeration |
Definition |
Defaults for patient gender |
Comments |
|
Constraints |
ct:EDXLStringType |
Valid Values / Examples |
Male, Female, Unknown, ExtensionValue |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
tep: PatientAgeType |
Usage |
REQUIRED; MUST be used once, and only once [1..1] |
Definition |
Pairs age, whether or not the age has been estimated, and the age units used. |
Comments |
Complex Type top level "PatientAgeType" contains age, estimated, and age units. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL; MAY be used once but only once [0..1] |
Definition |
The patient race/ethnicity as defined by the OMB (US Office of Management and Budget) |
Comments |
|
Constraints |
Allow multiple selections. |
Valid Values / Examples |
valueListURI = urn:myagency:gov:ahrq:ethnicity_en Valid for value: White, African American, Asian, Hispanic/Latino. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
|
Element |
|
Type |
xsd:date |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
The patient's date of birth |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
“2001-10-26” |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:PersonDetailsType |
Usage |
OPTIONAL; MAY be used only once [0..*] |
Definition |
Includes identifying information like name, addresses, contact numbers, email addresses, and personal identifiers. |
Comments |
1. ID Number and type of personal ID (e.g. StateIssuing Drivers License) is captured in personal identifiers (PersonDetailsType.Identifiers) 2. TEP may carry multiple forms of identification. 3. This element MAY also be used in a ContentObject in the DE to uniquely identify attachments and other information such as a photograph. Where possible, an existing vetted list SHOULD be offered as defaults, but allow users to extend values on that list, or to use their own value list |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueKeyType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
The patient hair color |
Comments |
Source: [NIEM] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
Examples for value: Blonde, Black. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueKeyType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
The patient eye color |
Comments |
Source: [NIEM] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
Examples for value: Blue, Brown, Green. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
Distinguishing marks on the patient |
Comments |
|
Constraints |
|
Valid Values / Examples |
Examples: Birthmark, tattoo, scars. |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
One or more languages fluently spoken by the patient |
Comments |
NOTE: Recommend use of the UN list (used in CAP, SitRep or the DE). Format XX-XX |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
valueListURI = urn:myagency:gov:ahrq:languages_en value: English, Spanish, ... |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
A notation of patient transportation needs based on patient condition or other special needs, to assure safe transport. |
Comments |
Source: [AHRQ Natl Patient / Evacuee Track Sys] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
ValueListURI = urn:myagency:gov:ahrq:specialTransportationNeeds value: Advanced Life Support, Basic Life Support, Bariatric, Stretcher Need, Stokes Basket. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
A notation of special medical needs or advanced directives patients may have, such as a DNR to assure that patients with these needs reach a location equipped to meet them. |
Comments |
Source: [AHRQ Natl Patient / Evacuee Track Sys] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
ValueListURI = urn:myagency:gov:ahrq:specialMedicalNeeds value: ventilator, oxygen, dialysis, Do Not Resuscitate Order. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
The patient’s medication allergies. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
|
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
tep: MedicationType |
Usage |
OPTIONAL; MAY be used more than once [0..*] |
Definition |
The medications the patient currently takes. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
A unique code that is assigned and tracked to individuals believed to be part of the same family unit, designed to link family members to each other. Purpose is to assist family reunification. |
Comments |
Source: [AHRQ Natl Patient / Evacuee Track Sys] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
A notation of special communication needs to help arrange for translator services or services for hearing or vision impaired persons. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References, [HL7 2.7.1] referenced in section 1.5 Normative References, [AHRQ Natl Patient / Evacuee Track Sys] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
valueListURI = urn:myagency:gov:ahrq:specialMedicalNeeds value: Translator, Hearing Impaired, Vision Impaired. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
|
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
A patient status used in hospital, nursing home or other evacuations, to indicate current care requirement, to ensure transfer to an appropriate receiving facility with the same or similar care environment or capability |
Comments |
Source: [AHRQ Natl Patient / Evacuee Track Sys] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
ElementType |
|
Type |
xsd:enumeration |
Definition |
Defaults for patient evacuation status |
Comments |
The default values offer a vetted list |
Constraints |
ct:EDXLStringType |
Valid Values / Examples |
ICU, Floor, DischargeReady, |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:PersonDetailsType |
Usage |
OPTIONAL; MAY be used once, but only once [0..1] |
Definition |
A patient's contact information. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:PersonDetailsType |
Usage |
OPTIONAL; MAY be used more than once [0..*] |
Definition |
A patient's closest relative, guardian, emergency contact, or attendant’s contact information. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
|
Usage |
OPTIONAL; MAY be used more than once [0..*] |
Definition |
Could contain NDMS, specialSecurityNeeds, others.. |
Comments |
Source: [AHRQ Natl Patient / Evacuee Track Sys] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
Example for value: securitySupervisionNeeds: Indication that a patient may require special security for their own protection or that of others, such as prisoners, psychiatric patients, domestic abuse victims. |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
ElementType |
|
Type |
xsd:enumeration |
Definition |
Defaults for patient special classification |
Comments |
The default values offer a vetted list |
Constraints |
ct:EDXLStringType |
Valid Values / Examples |
SecuritySupervisionNeeds, NDMSPatient |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
tep: SituationType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
Group of elements used to describe the incident associated with the patient |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 1, 8 |
Element |
|
Type |
|
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
Group of elements used for identifying and describing a certified care provider (typically Emergency Medical Services personnel). |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
|
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
Group of elements used to describe an instance of an encounter between a patient and an EMS Care Provider. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 12 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Group of elements used to describe the incident associated with the patient |
Comments |
This element is always paired with incidentID and incidentType whether one or multiple instances of the pairing are used. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- incidentID [1..*]: tep:IncidentIDType - incidentLocation [1..1]: ct:EDXLLocationType - incidentStartDateTime [0..1]: ct:EDXLDateTimeType - relatedIncidentID [0..*]: ct:EDXLStringType |
Used In |
|
Requirements Supported |
iReq# 1, 8 |
Element |
|
Type |
tep: IncidentIDType |
Usage |
REQUIRED: MUST be used at least once [1..*] |
Definition |
Identifies (by name, number or other identifier and type) the incident associated with the patient, to which the current TEP message refers. |
Comments |
Different agencies or jurisdictions may use different IDs for the incident. TEP MAY carry more than one. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 1, 8 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Groups the name, ID and incident type (kind). |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- name [1..1]: ct:EDXLStringType - ID [1..1]: ct:EDXLStringType - kind [1..1]: ct:ValueListType - source [1..1] ct:EDXLStringType |
Used In |
|
Requirements Supported |
iReq# 1, 8 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The name assigned to the incident (often by the Incident Commander or Agency). |
Comments |
Different agencies or jurisdictions may use different names for the incident. TEP MAY carry one or more. |
Constraints |
This element is always paired with incidentID.ID, incidentID.kind, and incidentID.source whether one or multiple instances of the pairing are used. |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 1, 8 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
A number or other identifier of the incident that has been assigned by an authorized agency based on current guidance. |
Comments |
The ID may vary by jurisdiction and profession (e.g. law enforcement vs. Fire). It may be a computer aided dispatch number, an accounting number, a disaster declaration number, or a combination of the state, unit/agency, and dispatch system number. |
Constraints |
This element is always paired with incidentID.name, incidentID.kind, and incidentID.source whether one or multiple instances of the pairing are used. |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 1, 8 |
Element |
|
Type |
ct:ValueListType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
General definition, category or kind of the incident. |
Comments |
|
Constraints |
1. This element is always paired with incidentID.name, incidentID.ID, and incidentID.kind whether one or multiple instances of the pairing are used. 2. Allow multiple selections. |
Valid Values / Examples |
Example for value: CBRNE ( Chemical, Biological, Nuclear, Explosives),Natural Disaster, Day to Day, etc. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 1, 8; fReq# 6 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The agency or organization that assigned the incident ID |
Comments |
Different agencies or jurisdictions may use different names for the incident. |
Constraints |
This element is always paired with incidentID.name, incidentID.ID, and incidentID.kind whether one or multiple instances of the pairing are used. |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
|
Element |
|
Type |
ct:EDXLLocationType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The physical location of the incident. |
Comments |
1. Captures location information in a variety of forms including geopolitical (e.g. addresses) and geospatial (e.g. lat/long). 2. Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
|
Element |
|
Type |
ct:EDXLDateTimeType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The Date and Time the Incident started or was first observed. |
Comments |
1. The date and time is represented in [XML Schema] 3.2.7 dateTime format (e. g., "2002-05-24T16:49:00-07:00" for 24 May 2002 at 16: 49 PDT), referenced in section 1.5 Normative References. 2. Alphabetic timezone designators such as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00” or “+00:00. May come from formal declaration, day to day CAD system etc. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 1, 8 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used more than once [0..*] |
Definition |
Identifier for a large scale incident (e.g. a Hurricane) which the current patient / Care Provider / Incident is associated with in some way. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 1, 8 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Group of elements used for identifying and describing a certified care provider (typically Emergency Medical Services personnel) |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- 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 |
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
ct:ValueKeyType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The state assigned provider number of the responding agency or hospital |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The formal name of the agency or hospital associated with the care provider. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
xal:AddressType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The geographic jurisdiction (state, province, etc.) in which the Agency or Hospital associated with the care provider provides services |
Comments |
Country and AdministrativeArea are the only two Required elements of AddressType (inherited from CIQ) for use in TEP. Defaults to U.S. States. |
Constraints |
|
Valid Values / Examples |
Valid Values: e.g. States such as AL, AK, AZ, etc., Province Name, or other applicable jurisdictions |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
ct:ValueKeyType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
|
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1]: ct:ValueType |
Used In |
|
Requirements Supported |
|
Element |
|
Type |
ct:ValueListType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The type of service provided by the care provider agency |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
Valid for value: ED, EMS, Hospital, Intermediate Care Facility |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
An agency or hospital identifier based on domain naming convention. |
Comments |
1. Next Generation 911 practitioners have indicated that a networking domain-type naming convention is in the process of being implemented for the purpose of identifying emergency responders. 2. Source: [NENA-Next Generation 911] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
fd.pittsburgh.pa.us |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
State or local Agency / Hospital ID number for the EMS-Care Provider |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
xal:AddressType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
EMS-Care Provider's jurisdiction of certification or credentialing (state, province, etc.) |
Comments |
Country and AdministrativeArea are the only two Required elements of AddressType (inherited from CIQ) for use in this element. |
Constraints |
|
Valid Values / Examples |
AL, AK, AZ, etc. |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 9
|
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The medical certification level of the responding care provider |
Comments |
|
Constraints |
Allow multiple selections. |
Valid Values / Examples |
Valid for value: EMT, Nurse, Doctor |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 9 |
Element |
|
Type |
tep: TransportType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
Group of elements used for identifying and describing a conveyance (vehicle) used to transport a patient |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 10 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Group of elements used for identifying and describing a conveyance (vehicle) used to transport a patient |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- unitNumber [0..1]: ct:EDXLStringType - vehicleKind [0..1]: ct:ValueKeyType - vehicleProvider [0..1]: ct:EDXLStringType - vehicleJurisdiction [1..1]: xal:AddressType |
Used In |
|
Requirements Supported |
iReq# 10 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
CONDITIONAL: MAY be used once but only once [0..1] |
Definition |
The EMS/Responder vehicle unit number of the vehicle used for patient conveyance. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
CONDITIONAL (If "providerKind" is EMS, then "unitNumber" is REQUIRED) |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 10 |
Element |
|
Type |
ct:ValueKeyType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
Vehicle type of responding unit or vehicle of patient conveyance |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
Examples for value: Ambulance, fire truck, bus, helicopter etc. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 10 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
|
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 10 |
Element |
|
Type |
xal:AddressType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The Jurisdiction (e.g. state, province) in which the vehicle unitNumber is registered |
Comments |
|
Constraints |
|
Valid Values / Examples |
AL, AK, AZ, etc. |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 10 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Group of elements used to describe an instance of an encounter between a patient and an EMS Care Provider |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- encounterID [1..1]: ct:EDXLStringType - encounterDateTime [1..1]: ct:EDXLDateTimeType - locationCategory [1..1]: ct:ValueKeyType - encounterLocation [1..1]: ct:EDXLLocationType - patientCare [1..*]: tep:PatientCareType - patientTransfer [0..*]: tep:PatientTransferType |
Used In |
|
Requirements Supported |
iReq# 12 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
A unique ID identifying an instance of the first or initial encounter between a patient and an EMS Care Provider |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 12 |
Element |
|
Type |
ct:EDXLDateTimeType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
Date and Time of patient-EMS-Care Provider initial encounter |
Comments |
1. The date and time is represented in [XML Schema] 3.2.7 dateTime format (e. g., "2002-05-24T16:49:00-07:00" for 24 May 2002 at 16: 49 PDT),. referenced in section 1.5 Normative References. 2. Alphabetic timezone designators such as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00” or “+00:00. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 12 |
Element |
|
Type |
|
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The type of location where EMS-Care Providers encounter the patient |
Comments |
|
Constraints |
|
Valid Values / Examples |
Examples for value: Emergency Department, Scene, Intermediate Care, etc. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 12 |
Element |
|
Type |
ct:EDXLLocationType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The physical location of the instance of an encounter between a patient and an EMS Care Provider. Capability is required to express and capture location information in a variety of forms including geopolitical (e.g. addresses) and geospatial (e.g. lat/long). |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 12 |
Element |
|
Type |
tep: PatientCareType |
Usage |
REQUIRED: MUST be used at least once [1..*] |
Definition |
Group of elements used to describe Care Provider observations, evaluations, electronic measures and actual treatments and procedures taken for or performed on the patient at a particular point in time. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
tep: PatientTransferType |
Usage |
OPTIONAL: MAY be used more than once [0..*] |
Definition |
Group of elements used to describe and track physical movement or transport of a patient. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 13 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Group of elements used to describe Care Provider observations, evaluations, electronic measures and actual treatments and procedures taken for or performed on the patient at a particular point in time. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- 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 - ContingencyMedicalSpecialtyCode [0..1]: tep: ContingencyMedicalSpecialtyCodeDefaultValues |
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
A unique ID identifying a patient’s care record. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:EDXLDateTimeType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The date and time that any observations, evaluations, electronic measures and actual treatments and procedures were recorded. Also used to uniquely identify the care record, providing the date/time for that set of care attributes. |
Comments |
1. For example, this is the [XML Schema] 3.2.7 dateTime, referenced in section 1.5 Normative References, associated with the chief complaint given, and each vital sign taken (heart rate, temperature, blood temperature etc.). 2. The date and time is represented in [XML Schema] 3.2.7 dateTime format (e. g., "2002-05-24T 16:49:00-07:00" for 24 May 2002 at 16: 49 PDT), referenced in section 1.5 Normative References. 3. Alphabetic timezone designators such as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00” or “+00:00. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
|
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
Triage color for individuals assessed by medical personnel prior to being transported. Triage Status sets priorities for treatment |
Comments |
Source: [AHRQ Natl Patient / Evacuee Track Sys] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
ElementType |
|
Type |
xsd:enumeration |
Definition |
Defaults for triage status |
Comments |
The default values offer a vetted list, but allow communities to add extensions |
Constraints |
ct:EDXLStringType |
Valid Values / Examples |
Red, Yellow, Green, Blue, Black, Unknown, ExtensionValue |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
|
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The state, status or outcome of a patient at the end of emergency care (i.e. at the point of patient admission, transfer, release, death…) |
Comments |
Note that disposition applies at EACH transfer point / encounter, NOT just at the end of the emergency care continuum. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
ElementType |
|
Type |
xsd:enumeration |
Definition |
Defaults for patient disposition |
Comments |
The default values offer a vetted list, but allow communities to add extensions |
Constraints |
ct:EDXLStringType |
Valid Values / Examples |
Discharged, Transferred, Deceased, NoTreatmentRequired, RefusedCare, TreatedAndReleased, TreatedAndTransferredCare, TreatedAndTransported, Admitted, TreatedAndTransportedToHospital, Pending-Ongoing, Unknown, ExtensionValue |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The statement of the problem verbalized by the patient or the care provider in one or two words |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:integer |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient systolic blood pressure |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Restricted to values 0-300 |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:integer |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient diastolic blood pressure |
Comments |
|
Constraints |
Restricted to values 0-300 |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:integer |
Usage |
OPTIONAL: MAY be used once and only once [0..1] |
Definition |
The patient pulse rate, palpated or auscultated, expressed as a number per minute. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Restricted to values 0-320 |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:integer |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient respiratory rate expressed as a number per minute. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Restricted to values 0-100 |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
Documentation of a patient's cardiac rhythm. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
Examples for value: Ventricular Fibrillation, Normal Sinus Rhythm, etc. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The interpretation of the patient's heart rhythm by the ECG device. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:PercentageType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient oxygen saturation. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:unsignedInt |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient’s end-tidal or other CO2 level. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:integer |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient blood glucose level. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Restricted to values 0-500. |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:DegreesCType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient body temperature in degrees Celsius/centigrade. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:integer |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The patient total Glasgow Coma Score (GCS). The GCS is a neurological scale that provides a consistent and objective method of assessing the conscious state of a person. The total score is the sum of the scores in three categories: eye opening response, verbal response, and motor response. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Restricted to values 3-15. |
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Medication and “administered” record |
Comments |
Describes medication used and the [XML Schema] 3.2.7 dateTime, referenced in section 1.5 Normative References, it has been administered. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- medication [1..1]: tep: MedicationType - administered [0..*]: ct:EDXLDateTimeType |
Used In |
|
Requirements Supported |
[HL7 2.7.1], referenced in section 1.5 Normative References, Pharmacy/Treatment Administration (RAS) transforms |
Element |
|
Type |
tep: MedicationType |
Usage |
REQUIRED [1..1] |
Definition |
The medication given to the patient. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:EDXLDateTimeType |
Usage |
OPTIONAL: MAY be used once or more [0..*] |
Definition |
Record of date/time the medication has been given to the patient. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References and [HL7 2.7.1], referenced in section 1.5 Normative References, RAS message type. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
|
Usage |
OPTIONAL: MAY be used more than once [0..*] |
Definition |
The medication given to the patient, when. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References and [HL7 2.7.1], referenced in section 1.5 Normative References, RAS message type. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL: MAY be used once, but only once [0..1] |
Definition |
The procedure(s) performed on the patient. |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
Examples for value: IV, CPR, Endotracheal Tube |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:ValueListType |
Usage |
OPTIONAL: MAY be used once, but only once [0..1] |
Definition |
The care provider personnel’s impression of the patient primary problem or most significant condition which led to the management given to the patient (treatments, medications, or procedures). |
Comments |
Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
Allow multiple selections. |
Valid Values / Examples |
Examples for value: Cardiac Arrest, Stroke, etc. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
Free form text field to communicate basic warning factors to Care Providers such as respiratory issues, tourniquet, fracture etc. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:boolean |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
A notation that an exposed patient needs to be segregated, quarantined, or decontaminated, to avoid putting others at risk. |
Comments |
1. “true” - Patient may be contaminated/exposed. 2. “false” - Patient has not been contaminated/exposed. |
Constraints |
|
Valid Values / Examples |
Valid values: True, False, Unknown |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
xsd:boolean |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
A set of criteria pertaining to the decision by pre-hospital personnel to transport trauma victims, to a specialized acute care facility (trauma center), versus an undesignated, non-specialized acute care facility. |
Comments |
1. The goal of the decision scheme is to match the clinical needs of an injured patient to the resources and expertise of a given facility to care for them. 2. “true” - Transport to trauma center 3. “false” - Transport according to protocol |
Constraints |
|
Valid Values / Examples |
Valid values: True, False |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 14 |
Element |
|
Type |
|
Usage |
OPTIONAL: MAY be used multiple times [0..*] |
Definition |
A code utilized across jurisdictions which assists patient recipient with determination of the bed or bed type needed to support that patient at destination. |
Comments |
As Hospital evacuation is part of TEP scope (movement and transport of medical evacuees/patients), in addition to states requesting federal assistance when local and state resources become overwhelmed, often DoD transport is requested, for example for air transport to other states. In this case the element "triageStatus" is not relevant as neither the hospitals use the "red", "yellow", etc. designations for patients in hospitals; nor DoD use or understand those designations. The “Contingency Medical Specialty Code” is an existing element that is utilized and understood across jurisdictions today. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
|
ElementType |
|
Type |
xsd:enumeration |
Definition |
Defaults for contingency medical specialty codes |
Comments |
The default values offer a vetted list |
Constraints |
ct:EDXLStringType |
Valid Values / Examples |
Pediatric, Burn, Psychiatric, MedicalSurge, CriticalCare |
Sub-elements |
|
Used In |
TEPMessage.patient.patientCare.contingencyMedicalSpecialtyCode |
Requirements Supported |
|
ElementType |
|
Type |
xsd:complexType |
Definition |
Group of elements used to describe and track physical movement or transport of a patient. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- destinationETA [0..1]: ct:EDXLDateTimeType - destination [1..1]: ct:EDXLLocationType - actualArrivalDateTime [0..1]: ct:EDXLDateTimeType - actualDepartureDateTime [0..1]: ct:EDXLDateTimeType |
Used In |
|
Requirements Supported |
iReq# 13 |
destinationETA |
|
Type |
ct:EDXLDateTimeType |
Usage |
OPTIONAL MAY be used once but only once [0..1] |
Definition |
Estimated time of arrival at intended destination |
Comments |
1. The date and time is represented in [XML Schema] 3.2.7 dateTime format (e. g., "2002-05-24 T16:49:00-07:00" for 24 May 2002 at 16: 49 PDT) referenced in section 1.5 Normative References. 2. (Alphabetic timezone designators such as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00” or “+00:00. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 13 |
Element |
|
Type |
ct:EDXLLocationType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The physical location that the patient is being transferred to. Capability is required to express and capture location information in a variety of forms including geopolitical (e.g. addresses) and geospatial (e.g. lat/long). |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 13 |
Element |
|
Type |
ct:EDXLDateTimeType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The date/time the patient actually arrived at the destination. Business Rule: At this step, would no longer have a destination (it would be wiped out at this point because the patient transfer is completed until the next transfer / destination is defined) |
Comments |
1. The date and time is represented in [XML Schema] 3.2.7 dateTime format (e. g., "2002-05-24 T16:49:00-07:00" for 24 May 2002 at 16: 49 PDT) referenced in section 1.5 Normative References. 2. Alphabetic timezone designators such as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00” or “+00:00. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 13 |
Element |
|
Type |
ct:EDXLdateTimeType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The date/time the patient departed from the current location |
Comments |
1. The date and time is represented in [XML Schema] 3.2.7 dateTime format (e. g., "2002-05-24 T 16:49:00-07:00" for 24 May 2002 at 16: 49 PDT) referenced in section 1.5 Normative References. 2. Alphabetic timezone designators such as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00” or “+00:00. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 13 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Describes Type and form of personal Identification |
Comments |
1. Pairs ID and ID source to uniquely identified patient. 2. ID Number and State Issuing Driver’s License is captured in PersonDetailsType – TEP may carry multiple forms of identification. This element MAY also be used in a <contentObject> in the DE to uniquely identify attachments and other information such as a photograph. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- ID [1..1]: ct:EDXLStringType - source [1..1]: ct:ValueListType |
Used In |
|
Requirements Supported |
iReq# 5, 11 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
A number or code issued to each patient encountered; used as a unique identifier of the patient. Always paired with source. |
Comments |
1. This element is always paired with patientID.source whether one or multiple instances of the pair are used. 2. The patientID.ID element may also be used in a ContentObject in the DE to uniquely identify attachments and other information such as a photograph. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 5, 11 |
Element |
|
Type |
ct:ValueListType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
A notation identifying the source of the patient's ID, to describe the source (who, what or where) that created the ID. |
Comments |
This element is always paired with patientID.ID whether one or multiple instances of the pair are used. |
Constraints |
|
Valid Values / Examples |
Examples for value: State of Maryland, JPTAS System, Hampshire County, WV, State of TN, NDMS etc. |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..*]: ct:ValueType |
Used In |
|
Requirements Supported |
iReq# 5, 11 |
ElementType |
|
Type |
xsd:complexType |
Definition |
Pairs age, whether or not the age has been estimated, and the age units used. · The patient age, either calculated from date of birth or best approximation is appropriate in situations where it is not possible to ascertain exact age. · estimated: valid values Y, N · List of unitsDefaultValues: Default age units |
Comments |
1. Complex Type top level "clientAge" contains age, estimated, and ageUnits. 2. Regarding units/unitsDefault: unitsDefault is a default units list that SHOULD be used if possible. If a different list needs to be used or the default list needs to be extended, units SHOULD be used. 3. Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
· age [1..1]: xsd:unsignedint · estimated [1..1]: ct:EstimateType · units [1..1]: tep:AgeUnitsDefaultValues |
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
xsd:unsignedInt |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The patient age. |
Comments |
1. The patient age, either calculated from date of birth or best approximation is appropriate in situations where it is not possible to ascertain exact age. 2. Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
ct:EstimateType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
Determines whether age is an estimate or not. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
Element |
|
Type |
|
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
Determines the units in which the age is documented |
Comments |
1. This is a custom list of age units that SHOULD be used only when necessary. 2. Source: [NEMSIS v2.2.1] referenced in section 1.6 Non-Normative References. |
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
ElementType |
|
Type |
xsd:enumeration |
Definition |
Defaults for patient age units |
Comments |
The default values offer a vetted list, but allow communities to add extensions |
Constraints |
ct:EDXLStringType |
Valid Values / Examples |
Hours, Days, Months, Years, ExtensionValue |
Sub-elements |
|
Used In |
|
Requirements Supported |
iReq# 11 |
ElemenType |
|
Type |
xsd:complexType |
Usage |
|
Definition |
Group of elements used to describe medication and medication usage. |
Comments |
|
Constraints |
|
Valid Values / Examples |
|
Sub-elements |
- name [1..1]: ct:ValueKeyType - dosage [0..1]: ct:EDXLStringType - route [0..1]: ct:ValueKeyType - frequency [0..1]: ct:EDXLStringType |
Used In |
TEPMessage.patient. currentMedication.medication; TEPMessage.patient.patientCare.medicationAdministered.medication |
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:ValueKeyType |
Usage |
REQUIRED: MUST be used once and only once [1..1] |
Definition |
The name of the medication being described. |
Comments |
|
Constraints |
|
Valid Values / Examples |
Examples for value: Metformin, Simvastatin |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1]: ct:ValueType |
Used In |
TEPMessage.patient. currentMedication.medication; TEPMessage.patient.patientCare.medicationAdministered.medication |
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The dosage of the medication. |
Comments |
|
Constraints |
|
Valid Values / Examples |
2 tablets |
Sub-elements |
|
Used In |
TEPMessage.patient. currentMedication.medication; TEPMessage.patient.patientCare.medicationAdministered.medication |
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:ValueKeyType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
How the medication should be administered. |
Comments |
|
Constraints |
|
Valid Values / Examples |
Oral, IV |
Sub-elements |
- valueListURI [1..1]: ct:ValueListURI - value [1..1]: ct:ValueType |
Used In |
TEPMessage.patient. currentMedication.medication; TEPMessage.patient.patientCare.medicationAdministered.medication |
Requirements Supported |
iReq# 14 |
Element |
|
Type |
ct:EDXLStringType |
Usage |
OPTIONAL: MAY be used once but only once [0..1] |
Definition |
The frequency with which the medication should be administered. |
Comments |
|
Constraints |
|
Valid Values / Examples |
every 24 hours. |
Sub-elements |
|
Used In |
TEPMessage.patient. currentMedication.medication; TEPMessage.patient.patientCare.medicationAdministered.medication |
Requirements Supported |
iReq# 14 |
NOTE: Glossary definitions contained herein are not intended to supersede existing definitions by any other organization or agency. Rather, these glossary items are provided in context of defining the EDXL-TEP draft messaging standard - solely in order to clarify requirements statements.
TERM OR ACRONYM |
DEFINITION |
Ack |
Acknowledgment |
AHRQ |
Agency for Healthcare Research and Quality |
APOE |
Arial Point of Embarkation |
ASPR |
HHS Assistant Secretary for Preparedness and Response |
CAD |
Computer Aided Dispatch |
CAP |
Common Alerting Protocol |
CDC |
Center For Disease Control and Prevention |
CID |
Control and Interoperability Division |
CIQ |
Customer Information Quality (a “contact information” standard) |
Constraint Schema |
A constraint schema is simply a subset of the standard reference schema which conforms to all the requirements and business rules of the reference schema. For example, an implementation of the TEP standard may eliminate selected optional elements, or enhance the definition of a required element. |
DE |
Distribution Element |
DHS |
US Department of Homeland Security |
EDXL |
Emergency Data eXchange Language |
EDXL-DE |
Emergency Data eXchange Language - Distribution Element |
EDXL-HAVE |
Emergency Data eXchange Language - Hospital aVailability Exchange |
EDXL-RM |
Emergency Data eXchange Language - Resource Messaging |
EIC |
Emergency Interoperability Consortium |
Element |
“Elements” are logical groupings of message elements or “tags” for purposes of defining message structure |
ElementType |
Type description of “element” |
EMT |
Emergency Medical Technician |
ER-EHR |
Emergency Responder Emergency Health Record |
ERM |
Element Reference Model |
EMS |
Emergency Medical Services |
ESF |
Emergency Support Functions |
ETA |
Estimated Time of Arrival |
Event |
For purposes of this messaging standard, “Situations”, “Incidents” and “Events” will be referred to generally as “incidents”. Situations in this context refer to occurrences of various scales - a collection of happenings, observations and actions that have been correlated on some basis that may require resources to perform Public Safety/Emergency/Disaster mitigation, planning and preparation, response or recovery. It is a generic term referring to occurrences of any scale that may require some form of Emergency Response and Management, and that requires tracking and information exchange. An Event is a planned situation (e.g. a parade in Washington DC). “Event” is also used to refer to a situation that has not been formally identified as an incident. Like an incident, may be assigned an official ID, name or other descriptive attributes. EDXL-TEP may refer to any situation whether an incident, event or other occurrence. |
HITSP |
Health Information Technology Standards Panel |
HL7 |
Health Level Seven (“a reference to the seventh layer of the ISO OSI Reference model also known as the application layer.” – http://en.wikipedia.org/wiki/Health_Level_7). |
HTTP |
Hypertext Transfer Protocol |
ID |
Identification |
Incident |
For purposes of this messaging standard, “Situations”, “Incidents” and “Events” will be referred to generally as “incidents”. Situations in this context refer to occurrences of various scales - a collection of happenings, observations and actions that have been correlated on some basis that may require resources to perform Public Safety/Emergency/Disaster mitigation, planning and preparation, response or recovery. A Situation can be an incident, an event, or any observable or predictable occurrence. It is a generic term referring to occurrences of any scale that may require some form of Emergency Response and Management, and that requires tracking and information exchange. “Incident” is viewed from the NIMS Emergency Management perspective as a formal or informal declaration of emergency or disaster by an organization at the state, local, federal level or by a jurisdiction. An incident may be assigned an official ID, name or other descriptive attributes. EDXL-TEP may refer to any situation whether an incident, event or other situation or occurrence. |
JPATS |
Joint Patient Assessment and Tracking System |
Jurisdiction |
In context of emergency response to incidents, “jurisdiction” has two similar definitions: 1. Reference to a geo-political area or location. A jurisdiction is pre-defined physical location or area over which legal authority extends. Though a jurisdiction itself is not a person, role, or title, a jurisdiction has assigned to it one or more government personnel with legal authority for certain types of decision-making such as allocation of emergency resources and invocation of mutual aid agreements. 2. Reference to an organization or agency that has “Authority” over something (such as an incident, or a set of identified resources). Jurisdiction in this sense may be general, such as “federal”, “city”, or “state”, or may be specific agency names such as “Warren County”, “US Coast Guard”, “Panama City”, and “NYPD”. |
NASEMSO |
National Association of State EMS Officials |
NDMS |
National Disaster Medical System |
NEMSIS |
National Emergency Medical System (EMS) Information System |
NIMS |
National Information Management System |
NLE |
National Level Exercise |
OASIS |
Organization for the Advancement of Structured Information Standards |
OIC |
Office for Interoperability and Compatibility |
POC |
Point of Contact |
PRA |
Patient Reception Area |
Profile |
(Taken from the OGC) (Note: Considerable confusion exists in discussion and definition of the concept of a “profile”. The following definition was submitted by the OGC; however reference within this document more closely conforms to the term “constraint schema”.) A profile of GML can be defined to enhance interoperability and to curtail ambiguity by allowing only a specific subset of GML. Application schemas can then conform to such a profile in order to take advantage of any interoperability or performance advantages that it offers in comparison with a complete GML. Such profiles can be defined for application schemas that are included in other OGC specifications. There are cases where reduced functionality is acceptable, or where processing requirements compel use of a logical subset of GML. For example, applications that do not need to handle [xlink] attributes, referenced in section 1.5 Normative References, in any form can adhere to a specific profile that excludes them; the constraint in this case would be to not use links. Other cases might include defining constraints on the level of nesting allowed inside tags (i.e. tree depth), or only allowing features with homogeneous properties as members of a feature collection. In many cases, such constraints can be enforced via new schemas; others may be enforced through procedural agreements within an information community. |
PSG |
Practitioner Steering Group |
RAS |
Pharmacy/Treatment Administration (HL7) |
RM |
Resource Messaging (EDXL-RM) |
S&T |
Science and Technology Directorate of DHS |
SAFECOM |
SAFECOM is a communications program within the Office for Interoperability and Compatibility (OIC) that provides research, development, testing and evaluation, guidance, tools and templates on communications-related issues to local, tribal, state, and Federal emergency response agencies working to improve emergency response through more effective and efficient interoperable wireless communications. |
SitRep |
Situation Report |
Situation |
For purposes of this messaging standard, “Situations”, “Incidents” and “Events” will be referred to generally as “incidents”. Situations in this context refer to occurrences of various scales - a collection of happenings, observations and actions that have been correlated on some basis that may require resources to perform Public Safety/Emergency/Disaster mitigation, planning and preparation, response or recovery. A Situation can be an incident, an event, or any observable or predictable occurrence. It is a generic term referring to occurrences of any scale that may require some form of Emergency Response and Management, and that requires tracking and information exchange. |
SOAP |
Simple Object Access Protocol |
TEP |
Tracking Emergency Patients |
SWG |
Standards Working Group |
URN |
Uniform Resource Name |
URI |
Uniform Resource Identifier |
UTC |
Coordinated Universal Time |
XML |
eXtensible Markup Language |
An [XML 1.0] instance, referenced in section 1.5 Normative References, that begins with the <TEPMessage> as its root element is a conforming EDXL-TEP-v1.1 Message if and only if:
a) it meets the general requirements specified in Section 4;
b) its [namespace], referenced in section 1.5 Normative References, name is "urn:oasis:names:tc:emergency:edxl:tep:1.1", and it is valid according to the schema located at http://docs.oasis-open.org/emergency/edxl-tep/v1.1/cs02/schema/edxl-tep-v1.1.xsd
c) its [namespace], referenced in section 1.5 Normative References name is "urn:oasis:names:tc:emergency:edxl:tep:1.1", and its content (which includes the content of each of its descendants) meets all the additional mandatory requirements provided in the specific subsection of Section 4 corresponding to the element’s name, as defined in Constraints.
Note: Only messages that fully comply with the EDXL-TEP specification and that are complete and schematically valid, may be referred to as a “TEP Message”.
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Participants:
Patti Aymond, IEM
Rex Brooks, NCOIC
Lizzie DeYoung, The MITRE Corporation
Tim Grapes, Individual
Werner Joerg, IEM
Elysa Jones, Individual
Donald McGarry, The MITRE Corporation
Camille Osterloh, Individual
Robert Torchon, Individual
Jeff Waters, DoD
Brian Wilkins, The MITRE Corporation
The EDXL-TEP-v1.0 XML Schema is provided here for convenience. The schema can be downloaded at the OASIS website:
http://docs.oasis-open.org/emergency/edxl-tep/v1.1/cs02/xsd/edxl-tep-v1.1.xsd
<?xml
version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ct="urn:oasis:names:tc:emergency:edxl:ct:1.0"
xmlns:xal="urn:oasis:names:tc:emergency:edxl:ciq:1.0:xal"
xmlns:tep="urn:oasis:names:tc:emergency:EDXL:TEP:1.1"
xmlns:ns1="urn:oasis:names:tc:emergency:edxl:tep:ct:1.0"
xmlns:ext="urn:oasis:names:tc:emergency:edxl:extension:1.0"
targetNamespace="urn:oasis:names:tc:emergency:EDXL:TEP:1.1"
elementFormDefault="qualified">
<xsd:import
namespace="urn:oasis:names:tc:emergency:edxl:ct:1.0"
schemaLocation="./ edxl-ct-v1.0-csd04/edxl-ct-v1.0.xsd"/>
<xsd:import namespace="urn:oasis:names:tc:emergency:edxl:ciq:1.0:xal"
schemaLocation="./edxl-ciq-v1.0-csd04/edxl-xAL.xsd"/>
<xsd:import
namespace="urn:oasis:names:tc:emergency:edxl:extension:1.0"
schemaLocation="./edxl-ext-v1.0/edxl-ext-v1.0.xsd"/>
<xsd:element name="TEPMessage">
<xsd:annotation>
<xsd:documentation>Group of elements used to
uniquely identify a TEP message and its source.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="messageID"
type="ct:EDXLStringType"/>
<xsd:element name="systemID"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="patient"
type="tep:PatientType"/>
<xsd:element name="extension"
type="ext:ExtensionType" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="PatientType">
<xsd:annotation>
<xsd:documentation>Group of elements used to
uniquely describe the patient.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="patientID"
type="tep:PatientIDType" maxOccurs="unbounded"/>
<xsd:element name="gender"
type="tep:GenderDefaultValues"/>
<xsd:element name="patientAge"
type="tep:PatientAgeType"/>
<xsd:element name="raceEthnicity"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element name="dateOfBirth"
type="xsd:date" minOccurs="0"/>
<xsd:element name="personalID"
type="ct:PersonDetailsType" minOccurs="0"/>
<xsd:element name="hairColor"
type="ct:ValueKeyType" minOccurs="0"/>
<xsd:element name="eyeColor" type="ct:ValueKeyType"
minOccurs="0"/>
<xsd:element name="distinguishingMarks"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="fluentSpokenLanguages"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element
name="specialTransportationNeeds" type="ct:ValueListType"
minOccurs="0"/>
<xsd:element name="specialMedicalNeeds"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element name="medicationAllergies"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element name="currentMedication"
type="tep:MedicationType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="familyUnificationCode"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="barriersToPatientCare"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element name="evacuationDestinationRequired"
type="tep:PatientEvacuationDestinationRequiredDefaultValues"
minOccurs="0"/>
<xsd:element
name="patientContactInformation"
type="ct:PersonDetailsType" minOccurs="0"/>
<xsd:element
name="closestRelativeGuardianContactInformation"
type="ct:PersonDetailsType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="specialClassification"
type="tep:SpecialClassificationDefaultValues" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="situation"
type="tep:SituationType"/>
<xsd:element name="healthCareProvider"
type="tep:HealthCareProviderType"/>
<xsd:element name="patientEncounter"
type="tep:PatientEncounterType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SituationType">
<xsd:annotation>
<xsd:documentation>Group of elements used to
describe the incident associated with the patient.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="incidentID"
type="tep:IncidentIDType" maxOccurs="unbounded"/>
<xsd:element name="incidentLocation"
type="ct:EDXLLocationType"/>
<xsd:element name="incidentStartDateTime"
type="ct:EDXLDateTimeType" minOccurs="0"/>
<xsd:element name="relatedIncidentID"
type="ct:EDXLStringType" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="HealthCareProviderType">
<xsd:annotation>
<xsd:documentation>Group of elements used for
identifying and describing a certified care provider (typically Emergency
Medical Services personnel).</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="providerNumber"
type="ct:ValueKeyType"/>
<xsd:element name="providerName"
type="ct:EDXLStringType"/>
<xsd:element name="providerJurisdiction"
type="xal:AddressType"/>
<xsd:element name="providerCountry"
type="ct:ValueKeyType"/>
<xsd:element name="providerKind"
type="ct:ValueListType"/>
<xsd:element name="providerDomainName"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="personnelIDNumber"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="personnelJurisdiction"
type="xal:AddressType" minOccurs="0"/>
<xsd:element
name="personnelCertificationLevel" type="ct:ValueListType"
minOccurs="0"/>
<xsd:element name="transport"
type="tep:TransportType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="TransportType">
<xsd:annotation>
<xsd:documentation>Group of elements used for
identifying and describing a conveyance (vehicle) used to transport a
patient.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="unitNumber"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="vehicleKind"
type="ct:ValueKeyType" minOccurs="0"/>
<xsd:element name="vehicleProvider"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="vehicleJurisdiction"
type="xal:AddressType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PatientEncounterType">
<xsd:annotation>
<xsd:documentation>Group of elements used to
describe an instance of an encounter between a patient (patient) and an EMS
Care Provider.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="encounterID"
type="ct:EDXLStringType"/>
<xsd:element name="encounterDateTime"
type="ct:EDXLDateTimeType"/>
<xsd:element name="locationCategory"
type="ct:ValueKeyType"/>
<xsd:element name="encounterLocation"
type="ct:EDXLLocationType"/>
<xsd:element name="patientCare"
type="tep:PatientCareType" maxOccurs="unbounded"/>
<xsd:element name="patientTransfer" type="tep:PatientTransferType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PatientCareType">
<xsd:annotation>
<xsd:documentation>Group of elements used to
describe Care Provider observations, evaluations, electronic measures and
actual treatments and procedures taken for or performed on the patient at a
particular point in time.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="patientCareRecordID"
type="ct:EDXLStringType"/>
<xsd:element
name="patientCareRecordDateTime"
type="ct:EDXLDateTimeType"/>
<xsd:element name="triageStatus"
type="tep:TriageStatusDefaultValues"/>
<xsd:element
name="patientCurrentDisposition"
type="tep:PatientCurrentDispositionDefaultValues"/>
<xsd:element name="chiefComplaint"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="systolicBloodPressure"
minOccurs="0">
<xsd:simpleType>
<xsd:restriction
base="xsd:integer">
<xsd:minInclusive
value="0"/>
<xsd:maxInclusive
value="300"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="diastolicBloodPressure"
minOccurs="0">
<xsd:simpleType>
<xsd:restriction
base="xsd:integer">
<xsd:minInclusive
value="0"/>
<xsd:maxInclusive
value="300"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="pulseRate"
minOccurs="0">
<xsd:simpleType>
<xsd:restriction
base="xsd:integer">
<xsd:minInclusive
value="0"/>
<xsd:maxInclusive
value="320"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="respiratoryRate"
minOccurs="0">
<xsd:simpleType>
<xsd:restriction
base="xsd:integer">
<xsd:minInclusive
value="0"/>
<xsd:maxInclusive
value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="cardiacMonitorRhythm"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element
name="twelveLeadECGInterpretation" type="ct:EDXLStringType"
minOccurs="0"/>
<xsd:element name="pulseOximetry"
type="ct:PercentageType" minOccurs="0"/>
<xsd:element name="CO2Level"
type="xsd:unsignedInt" minOccurs="0"/>
<xsd:element name="bloodGlucoseLevel"
minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive
value="0"/>
<xsd:maxInclusive
value="500"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="temperature"
type="ct:DegreesCType" minOccurs="0"/>
<xsd:element name="totalGCS"
minOccurs="0">
<xsd:simpleType>
<xsd:restriction
base="xsd:integer">
<xsd:minInclusive
value="3"/>
<xsd:maxInclusive
value="15"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="medicationAdministered"
type="tep:MedicationAdministeredType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="proceduresPerformed"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element
name="careProviderPrimaryImpression"
type="ct:ValueListType" minOccurs="0"/>
<xsd:element name="seriousConcerns"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element
name="contaminationRadiationContagionStatus"
type="xsd:boolean" minOccurs="0"/>
<xsd:element
name="acsCDCFieldTraumaCriteria" type="xsd:boolean" minOccurs="0"/>
<xsd:element
name="contingencyMedicalSpecialtyCode"
type="tep:ContingencyMedicalSpecialtyCodeDefaultValues"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PatientTransferType">
<xsd:annotation>
<xsd:documentation>
Group of elements used to describe and track
physical movement or transport of a patient.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="destinationETA"
type="ct:EDXLDateTimeType" minOccurs="0"/>
<xsd:element name="destination"
type="ct:EDXLLocationType"/>
<xsd:element name="actualArrivalDateTime"
type="ct:EDXLDateTimeType" minOccurs="0"/>
<xsd:element name="actualDepartureTime"
type="ct:EDXLDateTimeType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="IncidentIDType">
<xsd:sequence>
<xsd:element name="name"
type="ct:EDXLStringType"/>
<xsd:element name="ID"
type="ct:EDXLStringType"/>
<xsd:element name="kind"
type="ct:ValueListType"/>
<xsd:element name="source"
type="ct:EDXLStringType" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MedicationType">
<xsd:sequence>
<xsd:element name="name"
type="ct:ValueKeyType"/>
<xsd:element name="dosage"
type="ct:EDXLStringType" minOccurs="0"/>
<xsd:element name="route"
type="ct:ValueKeyType" minOccurs="0"/>
<xsd:element name="frequency"
type="ct:EDXLStringType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MedicationAdministeredType">
<xsd:sequence>
<xsd:element name="medication"
type="tep:MedicationType"/>
<xsd:element name="administered"
type="ct:EDXLDateTimeType" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PatientIDType">
<xsd:sequence>
<xsd:element name="ID"
type="ct:EDXLStringType"/>
<!-- <xsd:element name="source"
type="ct:EDXLStringType"/> -->
<xsd:element name="source"
type="ct:ValueListType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PatientAgeType">
<xsd:sequence>
<xsd:element name="age"
type="xsd:unsignedInt"/>
<xsd:element name="estimated"
type="ct:EstimateType"/>
<xsd:element name="units"
type="tep:AgeUnitsDefaultValues"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="GenderDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration value="Male"/>
<xsd:enumeration value="Female"/>
<xsd:enumeration value="Unknown"/>
<xsd:enumeration
value="ExtensionValue"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="AgeUnitsDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration value="Hours"/>
<xsd:enumeration value="Days"/>
<xsd:enumeration value="Months"/>
<xsd:enumeration value="Years"/>
<xsd:enumeration value="ExtensionValue"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TriageStatusDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration value="Red"/>
<xsd:enumeration value="Yellow"/>
<xsd:enumeration value="Green"/>
<xsd:enumeration value="Blue"/>
<xsd:enumeration value="Black"/>
<xsd:enumeration
value="ExtensionValue"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType
name="PatientCurrentDispositionDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration value="Discharged "/>
<xsd:enumeration value="Transferred"/>
<xsd:enumeration value="Deceased"/>
<xsd:enumeration
value="NoTreatmentRequired"/>
<xsd:enumeration value="RefusedCare"/>
<xsd:enumeration value="TreatedAndReleased"/>
<xsd:enumeration
value="TreatedAndTransferredCare"/>
<xsd:enumeration
value="TreatedAndTransported"/>
<xsd:enumeration value="Admitted"/>
<xsd:enumeration
value="TreatedAndTransportedToHospital"/>
<xsd:enumeration value="Pending-Ongoing"/>
<xsd:enumeration
value="ExtensionValue"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType
name="PatientEvacuationDestinationRequiredDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration value="ICU "/>
<xsd:enumeration value="Floor"/>
<xsd:enumeration
value="DischargeReady"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType
name="ContingencyMedicalSpecialtyCodeDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration value="Pediatric"/>
<xsd:enumeration value="Burn"/>
<xsd:enumeration value="Psychiatric"/>
<xsd:enumeration value="MedicalSurge"/>
<xsd:enumeration value="CriticalCare"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SpecialClassificationDefaultValues">
<xsd:restriction base="ct:EDXLStringType">
<xsd:enumeration
value="SecuritySupervisionNeeds"/>
<xsd:enumeration value="NDMSPatient"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
The EDXL-TEP-v1.0 XML Schema imports a separate schema for Extensions
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ext="urn:oasis:names:tc:emergency:edxl:extension:1.0" xmlns:ct="urn:oasis:names:tc:emergency:edxl:ct:1.0" targetNamespace="urn:oasis:names:tc:emergency:edxl:extension:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:oasis:names:tc:emergency:edxl:ct:1.0" schemaLocation="./edxl-ct-v1.0-wd05.xsd"/>
<xs:complexType name="ExtensionType">
<xs:annotation>
<xs:documentation>
Base type to allow communities to extend/augment an EDXL data standard </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="community" type="xs:anyURI">
<xs:annotation>
<xs:documentation>Unique identifier of the community</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="id" type="xs:anyURI">
<xs:annotation>
<xs:documentation>Unique identifier for this extension</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="parameter" type="ext:ParameterType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ParameterType">
<xs:annotation>
<xs:documentation>Group of elements used to extend/augment an EDXL data standard </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="nameURI" type="ext:ParameterNameType">
<xs:annotation>
<xs:documentation>Unique identifier of a parameter</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="value" type="ext:ParameterValueType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ParameterNameType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="xPath" type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ParameterValueType">
<xs:simpleContent>
<xs:extension base="ct:EDXLStringType">
<xs:attribute name="uom" type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Revision |
Date |
Editor |
Changes Made |
edxl-tep-v1.0-wd03 |
01/11/13 |
Werner Joerg |
Working towards a first full Working Draft |
edxl-tep-v1.0-wd04 |
04/01/13 |
Werner Joerg |
Included EDXL-extension and adapted setup for defaults |
edxl-tep-v1.0-wd04 |
04/22/13 |
Werner Joerg |
Changed layout of Extension section with examples |
edxl-tep-v1.0-wd04 |
05/02/13 |
Werner Joerg |
More examples for Extension |
edxl-tep-v1.1-wd01 |
07/27/15
07/30/15 |
Werner Joerg |
Derived v1.1 from v1.0, adding MedicationAdministeredType for HL7-RAS transform. Fixed links; completed DD records for MedicationAdministeredType; |
edxl-tep-v1.1-csd01 |
08/04/15 |
Werner Joerg |
Transformed to .csd |
Edxl-tep-v1.1-csd02 |
12/15/2015 |
Patti Iles Aymond |
· Added non-normative references and cite reference consistently throughout document: o AHRQ Natl Patient / Evacuee Track Sys o NEMSIS v2.2.1 o NENA-Next Generation 911 o NIEM · Added non-normative reference and cite reference consistently throughout document: o XML Schema Part 2 · Remove uncited normative and non-normative references. · Move drafts from normative to non-normative references. · Correct references: o XLink o Schema o Namespaces o XML o RFC2119 · Sort normative and non-normative references into alphabetical order. · Modified Conformance for clarification: o Specified that additional mandatory requirements are defined in the Constraints property found in the data dictionary. o Replaced "element" with "instance that begins with the <TEPMessage> as its root element". · Add both versions of EDXL-DE to references: 1.0 is normative; 2.0 is non-normative, and added discussion about either version of a DE specification being acceptable where mentioned. · Cite all references (normative and non-normative) with bold face [label] and applicable section (where appropriate). · Corrected lower case “may” to upper case “MAY”, where appropriate; corrected lower case “should” to upper case “SHOULD”, where appropriate. · Corrected the use of “MUST”, as appropriate. · Fix document hyperlinks for the facilitation of document navigation (this required converting from *.odt to *.doc). |
Edxl-tep-v1.1-wd06 |
08/07/2018 |
Rex Brooks, Tim Grapes |
· Fix Section 5 Conformance to change edxl-tep-v1.0 to edxl-tep-v1.1 and fix Appendix B XML Schema for EDXL-TEP-v1.1 schema to change the schemaLocations of the three imported schema to reflect changes in folder Names to match new policy and further changes to reflect policy in the schema and ImportedSchema.folders, condensing the number of appearances of the imported schema to once each. |