edxl-tep requirements & draft messaging specification …9 final for submission to the 10 eic...
TRANSCRIPT
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 1
1
Emergency Data Exchange Language (EDXL) 2
Requirements Statement and Draft Messaging Specification 3
For the 4
PHASE II - Tracking of Emergency Clients 5
(EDXL-TEC) Messaging Standard 6
7
Version 1.6 8
FINAL for submission to the 9
EIC and OASIS 10
August 2012 11
12
Companion to Phase I: 13
Tracking of Emergency Patients (EDXL-TEP) 14
15
16
Prepared by SE Solutions, Inc. 17
Sponsored by the DHS S&T-OIC EDXL Program 18
Defined by the EDXL Practitioner Steering Group and TEC Steering Committee 19
20
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 2
Table of Contents 21
1 Introduction .......................................................................................................................................... 10 22
1.1 Purpose ............................................................................................................................................. 10 23
1.2 Background – TEP & TEC ................................................................................................................. 10 24
1.3 EDXL-TEC Phase II Overview .......................................................................................................... 13 25
1.3.1 Client Tracking Exchange ........................................................................................................... 15 26
1.3.2 Client Registry Exchange ........................................................................................................... 15 27
1.4 Outstanding Issues ............................................................................................................................ 16 28
1.4.1 EDXL-TEC security and privacy ................................................................................................. 16 29
1.4.2 EDXL-TEC “clients” and “vehicles” ............................................................................................. 17 30
1.5 Document Structure ........................................................................................................................... 18 31
1.6 Terminology ....................................................................................................................................... 20 32
2 EDXL-TEC Process and Compatibility ................................................................................................ 21 33
2.1 EDXL-TEC Definition Process ........................................................................................................... 21 34
2.2 Standards Compatibility..................................................................................................................... 21 35
2.3 EDXL Message Distribution .............................................................................................................. 21 36
2.3.1 EDXL Distribution Element (EDXL-DE) ...................................................................................... 22 37
2.3.2 Exchange Messaging Distribution .............................................................................................. 22 38
3 Common Technical Requirements ...................................................................................................... 23 39
3.1 General Requirements ...................................................................................................................... 23 40
3.2 Functional Requirements .................................................................................................................. 24 41
4 Tracking Exchange for Clients ............................................................................................................. 27 42
4.1 Tracking Exchange Message and Actors .......................................................................................... 27 43
4.2 Tracking Exchange Scenarios and Use Cases ................................................................................. 27 44
4.2.1 Use Case Variables .................................................................................................................... 28 45
4.2.2 Representative Use Case List .................................................................................................... 29 46
4.2.3 Use Case Events and Triggers ................................................................................................... 30 47
4.3 Tracking Exchange Statement of Requirements (Normative) ........................................................... 31 48
4.3.1 Functional Requirements ............................................................................................................ 32 49
4.3.2 Information Requirements .......................................................................................................... 33 50
4.3.3 Conformance Requirements ....................................................................................................... 43 51
4.4 Tracking Exchange Draft Message Specification .............................................................................. 44 52
4.4.1 Tracking Exchange Message Structure (Normative Unless Otherwise Stated) ......................... 44 53
5 Registry Exchange for Clients ............................................................................................................. 52 54
5.1 Registry Exchange Message and Actors .......................................................................................... 52 55
5.2 Registry Exchange Scenarios and Use Cases ................................................................................. 52 56
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 3
5.2.1 Representative Use Case List .................................................................................................... 53 57
5.2.2 Use Case Events and Triggers ................................................................................................... 53 58
5.3 Registry Exchange Statement of Requirements (Normative) ........................................................... 54 59
5.3.1 General Requirement ................................................................................................................. 54 60
5.3.2 Functional Requirements ............................................................................................................ 55 61
5.3.3 Information Requirements .......................................................................................................... 56 62
5.3.4 Conformance Requirements ....................................................................................................... 63 63
5.4 Registry Exchange Message Specification ....................................................................................... 64 64
5.4.1 Registry Exchange Message Structure (Normative Unless Otherwise Stated) ......................... 64 65
6 Data Dictionary (Normative) ................................................................................................................ 69 66
6.1 Data Dictionary Column Definitions ................................................................................................... 69 67
6.2 Routing Header Elements ................................................................................................................. 71 68
APPENDICES ............................................................................................................................................. 72 69
APPENDIX A - EDXL-TEC Steering Committee Acknowledgements .................................................... 72 70
APPENDIX B - Glossary / List of Acronyms ............................................................................................ 75 71
APPENDIX C - Definitions ....................................................................................................................... 77 72
APPENDIX D – Open Issues................................................................................................................... 78 73
74
75
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 4
Document Distribution List 76
Name Distributed
(Yes / No)
Date
(mm/dd/yyyy)
EDXL- TEC Steering Committee (See Appendix A)
YES
April 2012 draft review, Formal review periods May 9 & June 1, 2012 followed by subsequent resolution sessions
TEC Project Stakeholder Groups, including the DHS-S&T-OIC Practitioner Steering Group (PSG), Standards Working Group (SWG), and practitioner-identified vendors
YES June 1, 2012 formal review period
Emergency Interoperability Consortium (EIC) – concluding draft
YES August 15, 2012
SDO – OASIS – concluding draft CC: Pending EIC
review August15 , 2012
Office of the Deputy Director, Office for Interoperability and Compatibility, U.S. Department of Homeland Security Science and Technology
YES Included on all distributions and review periods
Emergency Interoperability Consortium (EIC) – FINAL
YES August 31, 2012
SDO – OASIS - FINAL CC: Pending EIC
review August 31 , 2012
77
78
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 5
Approvals 79
Role Organization Authorized Person Response Date
EDXL-TEC Executive Steering
Committee
Each member representing their
constituent organization.
(Through current majority consensus processes
with published issues or objections)
(See Appendix A
– EDXL-TEC
Executive Steering
Committee)
All comments and issues formally recorded and
addressed. Outstanding Issues submitted to OASIS process for
disposition
2012 Review periods:
April draft, May 9
revision, June 1
revision, July -
August Working
sessions to resolve
outstanding issues.
Deputy Director, OIC and EDXL Program
Office for Interoperability and Compatibility, DHS Science and Technology
Denis Gusty Approved for OASIS
submission when finalized
August, 2012
80
Modification History 81
Author
Date
<mm/dd/yyyy> Reason Reviewers Version
Contractor, SE Solutions, Inc.
09/30/2011 Internal project team review iterations - Initial
Draft
TEC Internal Project Team Initial Drafts
Contractor, SE Solutions, Inc.
03/09/2012 Revised Initial Draft TEC Steering Committee 1.0
Contractor, SE Solutions, Inc.
03/14/2012 Revised Draft resulting from internal project
team review
Project Team 1.1
Contractor, SE Solutions, Inc.
05/04/2012 Revised Draft resulting from initial Steering
Committee review; and miscellaneous editorial
corrections
Project Team 1.2
Contractor, SE Solutions, Inc.
05/29/2012 Revised Draft resulting from second Steering
Committee review
TEC Steering Committee, PSG, SWG, Stakeholders and
Vendors
1.3
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 6
Author
Date
<mm/dd/yyyy> Reason Reviewers Version
Contractor, SE Solutions, Inc.
07/20/2012 Revised Draft resulting from second Steering
Committee review
TEC Steering Committee, PSG, SWG, Stakeholders and
Vendors
1.4
Contractor, SE Solutions, Inc.
08/16/2012 Finalize specification package for submission
to SDO
Final for submission to EIC and OASIS
1.5
Contractor, SE Solutions, Inc.
08/31/2012 Final specification package submitted to EIC, OIC and cc: SDO
No substantive changes from draft. Issues list updated for
EIC and OASIS review
1.6 final
82
83
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 7
Related work: 84
This specification is related to: 85
1. EDXL-TEC Project Charter - December 2010 86 http://www.evotecinc.com/TEC/ 87
2. EDXL-TEC Messaging Standard Research Report & Research Artifacts – December 2010 88 http://www.evotecinc.com/TEC/ 89
3. EDXL-TEC Project Initiation Document (PID) - November 2011 90 http://www.evotecinc.com/TEC/ 91
4. EDXL-TEC Stakeholders Comments (Issues) List 92 http://www.evotecinc.com/TEC/ 93
5. EDXL-TEP Messaging Standard Research Report & Research Artifacts – February 2010 94 http://www.evotecinc.com/TEP/ 95
6. AHRQ - Recommendations for a National Mass Patient and Evacuee Movement, Regulating, 96 and Tracking System – January 2009 97
7. EDXL Distribution Element v1.0 98 http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc 99
8. EDXL Resource Messaging v1.0 100 http://docs.oasis-open.org/emergency/edxl-rm/v1.0/os/EDXL-RM-v1.0-OS.doc 101
9. EDXL Hospital Availability Exchange v1.0 102 http://docs.oasis-open.org/emergency/edxl-have/os/emergency_edxl_have-1.0-spec-os.doc 103
10. EDXL Situation Reporting (SitRep) 104 (Specification development currently in-progress within the OASIS Emergency Management 105 Technical Committee (EM-TC)) process 106
107
108
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 8
Abstract: 109
NOTE: The EDXL-TEC “Project Initiation Document (PID) for the PHASE II - Tracking of Emergency 110 Clients (EDXL-TEC) Messaging Standard” is prerequisite reading to this Specification, providing 111 background, purpose, objectives, scope and EDXL overview. The PID can be found at the following link: 112 http://www.evotecinc.com/TEC/ 113
This specification, as those before it, supports the Emergency Data Exchange Language (EDXL) suite of 114 standards, defining the stakeholder / practitioner requirements and draft specification for an XML-based 115 “messaging” standard. The EDXL-Tracking of Emergency Clients, Phase II, standard is intended to 116 enable automated data exchange between disparate systems which support various emergency and 117 disaster preparedness, mitigation, response and recovery processes. 118
The EDXL-Tracking of Emergency Clients, Phase II, expands the Phase I scope, Tracking of Emergency 119 Patients (TEP), from strictly patient-focused, to support the capability for tracking of non-medical general 120 population (“clients”) such as evacuees, those sheltered in place, displaced or self-evacuating. Unlike 121 past EDXL practitioner definition efforts which defined one and only one data exchange standard, this 122 phase II specification defines TWO specific data exchanges which assist the overall tracking process: 123
124
1. Client tracking exchange: A standard data exchange between state, local, tribal and federal 125 systems used to assist the evacuation of clients. Exchanged information supports client tracking 126 from point of encounter with professionals, through disposition at a shelter or other location, 127 providing real-time information to responders, emergency management, coordinating 128 organizations and shelter facilities involved in incidents and the chain of non-medical care, 129 services and transport. 130
2. Client registry Exchange: A standard data exchange between the many federal, private industry 131 and NGO “Registry” systems in place today, facilitating the ability for any one registry system to 132 contain the combined information of many registry systems. All of these systems support the 133 same specific and unique purpose – allowing “clients” to register or update their current location 134 and status; thereby providing loved ones and supporting agencies rich “people-finding” data 135 sources. 136 The TEC Registry Exchange, based upon the existing People Finder Interchange Format (PFIF), 137 is designed to be a standard format for passing data records used to add or create new records in 138 one or more receiving registry systems, to update existing records, to delete records, and to 139 specify rules which define whether a particular record may be promulgated beyond the immediate 140 receiving system. 141 142
Viewed together, these two TEC phase II data exchanges support: 143
Richer data sources for search, people-finding and family reunification 144
More effective evacuation management and effective use of assets 145
Enables sharing of client information and movement, so that “regulation” processes are more 146 effective (i.e. special needs may be matched with known transportation, shelters and resources). 147
Supports gaps identified by HHS-AHRQ processes (Dept. of Health and Human Services-Agency 148 for Health and Research Quality) 149
Supports Emergency Support Function (ESF) #6 – Mass Care, Emergency Assistance, Housing, 150 and Human Services, providing information assisting the coordination of the delivery of these 151 services when local, tribal, and State response and recovery needs exceed their capabilities. 152
153
Although “Shelter Availability” information-sharing will be addressed in a later phase, evacuee “to/from” 154 locations and their common names (e.g. “Holton Community Center) are included in order to track 155
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 9
evacuee movement. This also supports ESF 8 functions for tracking those with special medical needs to 156 and from co-located Federal Medical Stations (FMS), and the need for tracking of non-medical care 157 givers, and family members accompanying patients. 158
159
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 10
1 Introduction 160
1.1 Purpose 161
EDXL-TEC (Tracking of Emergency Clients) definition is driven by cross-profession practitioner needs 162 comprised of a TEC Steering Committee, Practitioner Steering Group, and expanded set of stakeholder 163 groups and their identified vendors. These groups first drove development of the EDXL-TEC “Project 164 Initiation Document (PID) for the PHASE II - Tracking of Emergency Clients (EDXL-TEC) Messaging 165 Standard”. The PID is prerequisite to this specification, providing background, purpose, objectives, scope 166 and EDXL overview. The PID can be found at the following link: http://www.evotecinc.com/TEC/ 167
This “Requirements Statement and Draft Messaging Specification” addresses Phase II of the overall effort 168 for EDXL-TEC. With the PID objectives and scope as its foundation, it details the Stakeholder and 169 practitioner requirements and defines a messaging specification (information-sharing data dictionary and 170 message structure). This Specification describes the requirements for an XML-standard schema, which 171 may be implemented to carry a payload of information for exchange of emergency client and client 172 tracking information between multiple disparate systems. This is particularly valuable across various 173 jurisdictions such as state lines and between state and federal agencies. 174
This specification with the PID MUST be addressed jointly as a unified, comprehensive package; 175 representing emergency practitioner requirements. Where differences exist between the EDXL-TEC PID 176 and this specification, this specification shall take precedence. Information presented in the PID is not 177 duplicated in this Specification document. 178
Once consented, this package will be submitted to an open standards development organization 179 (OASIS). There, requirements will be developed into an open, XML-based technical standard by the 180 OASIS Emergency Management Technical Committee (EM-TC). Once finalized, the standard(s) are 181 published, free for use in the implementation of data exchanges across the various systems, jurisdictions 182 and professions which must coordinate and collaborate in support of emergencies and disasters. 183
Though requirements and inputs to this standard have been collected from cross-profession emergency 184 support practitioners and expressed in U.S.-based language and terms, the job of OASIS is to publish a 185 public, international standard. The format is intended to be used collaboratively with other EDXL 186 standards, and used over any data transmission system, including but not limited to the Simple Object 187 Access Protocol (SOAP) Hypertext Transfer Protocol (HTTP) binding. 188
1.2 Background – TEP & TEC 189
This specification represents the requirements for one of several standards under the Emergency Data 190 Exchange Language (EDXL) suite of standards. The combination of EDXL-TEP (patients), TEC phase II 191 (evacuees), and TEC phase III (shelter availability) will enable standardized data exchange to 192 coordinate and track patient and general clients regulation, location, movement, status, care and 193 family reunification – whether sick or injured, displaced, evacuated, sheltering in place, or 194 deceased. The selected public Standards Development Organization (SDO) OASIS will work with the 195 stakeholder community to determine how these requirements will ultimately be designed into one or more 196 standards for data exchange. 197
Requirements for tracking of patients and evacuees were instigated by several initiatives: 198
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 11
199 i) The Office of the National Coordinator (ONC) identified broad gaps which helped drive the IS-200
04 Emergency Responder Emergency Health Record (ER-EHR) & Use Cases, and the 201 HITSP (Health Information Technology Standards Panel) ER-EHR Interoperability 202 specification. Gaps and requirements from these efforts drove the need for TEP and TEC. 203
ii) The “Recommendations for a National Mass Patient and Evacuee Movement, Regulating, 204 and Tracking System” document, published by HHS – Agency for Health, Research and 205 Quality in partnership with other agencies was a driver for TEP and TEC. 206
iii) The National Association of State EMS Officials (NASEMSO) developed NEMSIS (National 207 Emergency Medical Services information system), which also identified the need for data 208 exchange standards to leverage the many patient tracking systems in use today. The 209 NEMSIS data taxonomy has been integrated into Health Level 7 (HL7), and TEP is re-using 210 applicable HL7 Vocabulary via NEMSIS 3.0. 211
iv) Driven by these requirements coupled by state and local practitioner and association 212 requirements, DHS S&T was requested to facilitate cross-organization definition of 213 requirements for tracking of both Patients and Evacuees 214
215
As the overall scope became more defined, the term “Client” was introduced as an overarching generic 216 term to encompass both patients and evacuees. The term “patient” was predominantly and appropriately 217 used within the EDXL-TEP definition scope. However, within this document, the term “Client” is used to 218 focus on non-medical clients including persons displaced, missing, evacuated, and sheltering in place as 219 described above. 220
Because this effort was large, often complicated, and required many state, local and federal agencies, 221 organizations and NGO’s, it was determined to break up the scope by defining requirements for each 222 component into phases. Each phase was directed by a cross-functional stakeholder Steering 223 Committees, with both participant and process continuity between each. As stated, OASIS, working with 224 these practitioner groups, will determine how each set of requirements will become one or more 225 standards, together supporting the full life-cycle of patient and evacuee movement, tracking, management 226 and decision-making. 227
Figure 1 below provides a graphical view of the overall TEC scope originally framed by the Steering 228 Committee, but annotated to specifically highlight areas addressed by this TEC phase II specification. 229
230
Phase I –EDXL-Tracking of Emergency Patients (TEP) 231 (Stakeholder definition stage is complete - currently in-progress in OASIS, in partnership with 232 HL7) 233 A standard for exchange of emergency patient and tracking data, providing “real-time” information 234 to responders and care facilities across the emergency medical care continuum (primarily but not 235 exclusively EMS). Used from the point of patient encounter until patient release from care, or 236 admission (“handoff”) to definitive care (such as an Emergency Department). TEP is aimed at 237 increased effectiveness of emergency medical management, patient tracking, and preparation for 238 emergency care, supporting local, day7 to day needs as well as mass care situations across 239 jurisdictions, 240
241
Phase II – EDXL-Tracking of Emergency Clients (TEC) 242 (The topic of this stakeholder specification – see abstract and Figure 2 below) 243 244
Phase III - Shelter Availability Exchange: 245
(Researched but not started) 246
Phase III supports exchange of Shelter availability information for use by evacuee movement 247 decision-makers and reporting up the chain of command. Similar to the EDXL-Hospital 248 Availability Exchange (HAVE), this phase in essence provides what HAVE does for patients, 249
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 12
supporting decisions about where to route clients by sharing shelter locations, capacity, status 250 and availability, capabilities, resources and services provided. 251 252
Phase IV - Transport Availability: 253
(Not started) 254
Phase IV supports exchange of public and private transport availability information, available 255 routes, weather conditions and other information that supports decisions about evacuation mode 256 of transportation and logistics. As initial requirements are defined, the intent is to map against 257 existing available standards such as EDXL-Resource Messaging (RM) to determine whether a 258 current capability exists. 259
260
A TEC current systems research stage was initiated in parallel with final stages of TEP, to identify and 261 analyze a representative set of applicable existing systems. Results are documented in the “EDXL-TEC 262 Messaging Standard Research Report & Research Artifacts” (referenced in the “related work” section). 263 Outreach was performed to identify the Steering Committee for this effort as well as other stakeholders. 264 Participants from the EDXL-TEP effort were included for continuity, with a number of additional state, 265 local and federal organizations, agencies, and SDO’s added, totaling 18 TEC Steering Committee 266 representatives in all (see APPENDIX A - EDXL-TEC Steering Committee Acknowledgements). 267
The EDXL-TEC Project Initiation Document (PID) was then developed and ratified defining the 268 background, purpose, objectives, and scope. 269
270
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 13
Decision Making(includes regulation and
regulating)
Transportation Vehicles
Routes
Shelter
Systems
Shelter
Information Location
Capacity
Services
Client
Information Special Needs
Supervision Requirements
Movement / Tracking
Client Information Functional Needs
Relationships (people,
things)
Location
Client
Tracking
Systems
“Registry”
Systems
PURPOSE
Standards-based Information-Sharing
between
local, state, federal and DoD
Tracking Systems and between
Registry systems. Creates rich
information assets to support Evacuee
decision-making and people-finding
FUNCTIONS SUPPORTED
“Richer” existing data-sources for:
Tracking of Evacuees
Sharing information to support People-
Finding
Family Notification and Re-unification
Matching evacuee needs with services
Evacuation Management & Decision-
making
DATA
Incident
Client Identification
Client Associations / Relationships,
Needs, Other Information
Client Physical Tracking / Location
Locations / names (i.e. Shelter name)
Emergency Responders / Services
Providers
Potential info-sharing (standard
XML messages):
1) Client Movement / Tracking
2) Client “Registry” Information (PFIF
review)
3) Shelter Availability
4) Transportation Availability
EDXL Resource
Message(s)
Transportation Resources
Planned
Phase IV
Planned
Phase III
271
Figure 1 - EDXL-Tracking of Emergency Clients (TEC) Purpose and Scope 272
273 274
1.3 EDXL-TEC Phase II Overview 275
Additional information about the two data exchanges specified in this document is contained in the next 276 two subsections. These information exchanges support the full life-cycle of emergency client tracking 277 throughout an incident, from the point of client encounter (physically or virtually), through release from a 278 shelter. 279
As a supplement to the abstract and introduction, Figure 2 below provides a view of the processes 280 supported and standards-based data exchanges enabled, as compared and contrasted with TEP on the 281 left side of the diagram. Two basic TEP examples for contrast include the following. Note that in contrast 282 with TEP, TEC addresses scope and requirements for client self-registration data exchange, not within 283 scope of TEP. 284
1. Simple, day to day occurrence of EMS arrival on scene, treating a patient, and transporting that 285 patient to an Emergency Department. In larger incidents, some intermediate facility or field 286 hospital may be involved prior to definitive care. 287
a. When released, patients again may become evacuees, which may require shelter 288 services. 289
2. Mass Casualty incident requiring patient evacuation from one or more hospitals to an airport, 290 where federal resources have deployed to assist. Federal resources transport patients to a 291 Patient Reception Area, where they are triaged, assigned to ambulances and transported to local 292 hospitals. 293
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 14
Initial Client Encounter
Patient (Includes
Deceased)Evacuee Self Evacuate
Sheltering In
Place
ED /
Intermediate
Care Facility
Shelter A
Shelter BED / NDMS
Definitive Care
TEP TEC
3. Physical Tracking
2. Client Identification
(Client Unique Identifier)
4. Person
Finding
Morgue
Evacuee Patient
Patient Tracking Systems
JPATS (Fed)
State/Local
JPTA (DoD)
Rel
ease
d
Released
NGO & Self-
Registration
Systems
“Local”
Databases
“State”
Databases
Self-
Register
Self-Register
General
Public
Search
Released Exit
Disposition/
Intended
Destination
Transferred to ED
1. Incident /
Event Information
Safe and
WellNEFRLS
TEC
TE
C
TEC
Register
Register
“Registry”
Systems
“Tracking”
Systems
“Federal”
Databases
Shelter C Register
TE
CT
EC
Authorized
Users
Self-Registration
Se
arc
h
Self-R
egis
ter
Hospitals/
Nursing
Homes
TEC
TEP
Released
Key
= Client Classification
= Client Movement
= Data Exchange
PRA
294
Figure 2 - EDXL-TEC Phase II Example Process & Data Exchange View 295
296
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 15
297
1.3.1 Client Tracking Exchange 298
299
The Client Tracking Exchange is used between the state, local, tribal and federal organization systems 300 when assisting the evacuation of clients. For phase II, automated data exchanges for available shelters 301 and transportation will not be available, but sharing of evacuee information will assist decisions on client 302 routing. 303
1. Evacuees are routed to appropriate shelter locations, and could also be transferred between one 304 shelter and another 305
2. These clients may be released or simply leave a shelter, in which case information about their 306 current disposition and communicated destination may be shared. 307
3. Evacuees may become sick or injured, becoming patients which may be transported (or self-308 present) to emergency departments, hospitals or field hospitals. 309
4. When released from medical care, patients become general population / evacuees, which may 310 require transport and/or shelter services. 311
As each client is identified for movement and tracking, this exchange carries data about each client and 312 their special needs, their associations (things) and relationships (people such as family members) and 313 their movement from place to place (locations). This information-sharing improves the ability to match 314 evacuee needs with known services, transportation, shelters and resources (a term commonly used in 315 HHS and DoD called “Regulation”), and facilitates family notification and reunification through use of 316 received tracking data in response to public calls and queries. 317
1.3.2 Client Registry Exchange 318
Today, many public and secured “Registry” systems are in place governed by private industry, or NGO’s 319 such as American Red Cross, Google and CNN, as well as government organizations such as FEMA. 320 These open registry systems are designed for open, public access used for registering your location and 321 status information during an evacuation, and allowing the public the search for their loved ones (i.e. “is my 322 Mom OK?”). Some registry systems have partnered to share data utilizing the “People Finder 323 Interchange Format (PFIF). The desire and requirement addressed in this specification facilitates the 324 transition of PFIF into EDXL with required and enhancements, to facilitate SDO governance of a Registry 325 System data exchange standard for broad-based exchange of data between any person registry systems. 326
The TEC Client Registry Exchange provides the ability for automated sharing of new or updated 327 information in a standard format with other exchange partner registry systems, where the date is used to 328 add or updates records in each receiving system. Thus a registry system receiving standard information 329 exchanges from several other systems will contain many more records for people to search and find their 330 loved ones. 331
Referring to Figure 2 Clients may register their information into any of a number of registry systems, in 332 one of several ways. 333
The “register” lines from each shelter to a database symbol, represents the possibility that clients 334 being sheltered may self-register or have assisted registration into a registry database 335
o Lines between database symbols represent a TEC Client Registry Exchange sharing 336 information between different registry systems 337
The “self-register” lines in the upper right (utilized by self-evacuees or sheltering-in-place) 338 represent public access to one of several available registry systems for self-registration. 339
o Again, lines between database symbols represent a TEC Client Registry Exchange 340 sharing information between different registry systems 341
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 16
The users in the lower right represent public users directly searching public registry systems for 342 loved ones, or authorized users searching secured systems. Users may also dial into “call 343 centers”, where authorized users may provide information to those appropriately vetted. 344
A public, international effort has implemented such a data exchange between some of these systems 345 through the “People Finder Interchange Format (PFIF). These and other PFIF exchange partners have 346 recognized that exchanging their records with other registry systems makes each system’s data more rich 347 and valuable as a source to support the public, providing “people-finding” capabilities in response to calls. 348
Through this EDXL effort, Google and their partners recognized the value of making PFIF an open, 349 international standard though submission to a public standards organization. Through this specification 350 and ensuing OASIS process, the goal for final publication of the standard is to meet current requirements 351 while addressing known enhancements for improvement. The goal for use of the standard is to improve 352 the process and expand use of the data exchange to additional registry exchange partners, improving 353 processes for search, people-finding and family re-unification across existing registry systems supported 354 by private industry, NGO’s, and federal, state, local and tribal entities. 355 356
1.4 Outstanding Issues 357
A separate issues list for the TEC project has been maintained since development and distribution of the 358 Project Initiation Document (PID), and may be found at the link shown below. This list maintains all issues 359 which remain open, in-process or closed, but filtered to highlight the open, high-priority issues. As of this 360 version, the vast majority of outstanding issues have been addressed, disposition documented in the 361 issues list, and documented resolution incorporated into this specification. However, a small number of 362 issues remain open for review and disposition. 363
Where appropriate, some issues may remain open for submission to the standards development 364 organization OASIS for final evaluation and disposition. The full issues list is contained in the submission 365 package and also can be found on the following site: 366
http://www.evotecinc.com/TEC/ 367
1.4.1 EDXL-TEC security and privacy 368
Security and privacy concerns, referencing HIPAA (Health Insurance Portability and Accountability Act) 369 and PII (Personally Identifiable Information), has been raised by some members of the TEC Steering 370 Committee in multiple forums, and research has been conducted in this area as it relates both to 371 development and implementation of data exchanges utilizing this standard. 372
This potential issue may be broken down into the following components for discussion and disposition: 373
1. The purpose of this effort is to define a standard format and structure to be used to package data 374 for electronic transmission from a system to one or many other systems. Potential security and 375 privacy concerns do not apply to this standards development effort; nor do they apply to the 376 resulting standard or resulting data exchange structure, since neither deal with actual data 377 values. 378
2. The EDXL-TEC Standard is designed to facilitate electronic transport of data in a standard format 379 between systems – just as EDXL-TEP. In regards to an implemented data exchange standard, 380 the data itself may potentially contain private and/or sensitive information. 381
3. To the extent possible or applicable, the EDXL effort will include metadata to assist with privacy 382 and security designation and handling, whether through the payload, or, more likely through the 383 EDXL routing mechanism (the EDXL-Distribution Element). 384
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 17
a. However, the EDXL Distribution Element (DE) is not an absolute requirement for routing 385 TEC or other EDXL payloads. Where broad interoperability across other EDXL 386 standards is required, the routing wrapper must include key metadata consistent with the 387 DE. Otherwise, an alternative mechanism such as Atom or RSS may incorporate specific 388 security appropriate to the need, as with the Client Registry Exchange. 389
4. The EDXL-TEP and TEC standards are not designed to carry information related to patient or 390 evacuee billing or insurance. Therefore, HIPAA requirements may not directly relate to these 391 standards. 392
a. Regardless, it is the responsibility of the organizations that are sharing information with 393 outside entities, whether electronic or otherwise, to put in place agreements and policy to 394 address security and privacy concerns, and adhere to applicable Health Insurance 395 Portability and Accountability Act (HIPAA), Health Information Technology for Economic 396 and Clinical Health Act, and Personally Identifiable Information (PII) requirements. 397
5. Organizational and system agreements and policy related to security and privacy should address 398 3 layers as it relates to data exchange initiatives: 399
a. “Data at rest” – Sending and receiving systems store the data which may be shared with 400 others, whether electronically or otherwise. Systems and applications themselves must 401 implement applicable security policy, as well as message brokering software 402 infrastructure IF design stores or retains “data at rest” at any point during transmission. 403
b. “Data in transit” – Data in an “in-transit” state once sent from one system, but not yet 404 received by one or more receiving systems. Applicable security policy must be 405 implemented to address this transit, whether through the internet (e.g. 128 bit 406 encryption), private networks or through middleware such as message brokering software 407 infrastructure. 408
c. Personnel security policy and procedures – Data exchanged using protocols such as 409 TEP and TEC often support “call center” processes, where data received is used to 410 advise caller of the status of family members and facilitate family notification or 411 reunification. 412
EDXL Distribution Element v1.0 413 http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc 414
415
It is worth noting that Health and Healthcare-related data exchanges performed between Hospitals, 416 Laboratories and physicians etc. typically occur over the internet utilizing HL7-based messaging 417 protocols. Standard internet security and encryption is used to protect data in motion, while security 418 protocols, process and procedures are implemented and adhered to regarding data at rest and in use by 419 personnel. 420
1.4.2 EDXL-TEC “clients” and “vehicles” 421
The state of Texas has consolidated their state-wide patient and evacuee tracking systems from many 422 down to three, and has implemented their own state-wide version of TEP/TEC far ahead of this effort, 423 offering opportunities to learn from their implementation experience. 424
Representatives of the state Emergency Management and HHS reviewed the TEP and TEC information-425 sharing models in detail, and shared a potential incompatibility issue. TEP/TEC compatibility with State of 426 Texas implementation and data exchange by the Texas WebEOC Interoperability Project (TWIRP) may 427 be dependent upon this issue. 428
The issue lies with the need to tie a person to either a vehicle or a location, where vehicle information 429 cannot be optional (i.e. vehicle is always required). In other words, a data exchange message MUST 430 always carry information about the vehicle transporting a client. The State of Texas implementation, as 431 well as the WebEOC vendor product, identify VEHICLES and LOCATIONS "at the top" of their data 432 exchange structure, which means tracking of any client is first dependent upon identification of a vehicle 433
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 18
in which they will be transported. They require unique identification of available vehicles and locations 434 first, prior to any specific client being identified or tracked. For example, they track a vehicle in transit to 435 clients, and then associate clients to the transport that is carrying them. This makes perfect sense in 436 most use cases, and perhaps in all use cases the state encounters. However, some TEC use cases are 437 not supported by this business rule, such as tracking of clients at any embarkation rally point, or the 438 Hurricane Katrina response need to track clients at the Super Dome for days prior to identification of 439 vehicle(s) to transport those clients. 440
It is noted that applications may design and handle known location data and vehicle data any way they 441 wish. In a system or application, this data may be sent, received, stored and then used to associate with 442 a client being tracked, whereas a data exchange simply utilizes data stored in those systems. 443
After further discussion and analysis, it is believed that the issue simply boils down to the “scope” 444 (business process beginning and end) of their current data exchanges vs. the scope of TEP and TEC. 445
The current TEC/TEP requirements and draft design for client tracking, driven by the majority of 446 practitioners represented, focuses data exchange primarily on CLIENTS (persons, who may be patients, 447 evacuees, sheltered in place, or self-evacuated), as the "primary key" for unique identification and 448 tracking. An exchange of patient or evacuee tracking data first requires identification of the person being 449 tracked (process starts with an “encounter” between a professional and a client). 450
Vehicles used to transport patients and evacuees are regarded as optional data that is always associated 451 with a client being tracked, as well as their care provider at any point in time. This is due to several use 452 cases identified, e.g. where evacuees may be tracked until available transport is identified. 453
Therefore, TEP/TEC simply treats sharing of information about available vehicles (resources) as a 454 separate data exchange (originally scoped as Phase IV of this effort for comparison with EDXL-RM 455 capabilities). An existing data exchange may provide others with information about existing locations 456 where clients may be moved to and from, as well as available transport to move them. TEP/TEC may 457 then be used (in the case of Texas, perhaps with new partners who adopt TEP/TEC) to share tracking 458 data from point of client encounter through the end of the movement and tracking process. 459
460
1.5 Document Structure 461
This document is organized into the following major sections and structure as shown below, which MUST 462 be considered in whole as well as jointly with the Project Initiation Document (PID) during the OASIS 463 process as the primary drivers of the standard. 464 465
The Document Structure, which follows, indicates two important factors regarding structure of this 466 document: 467
a. This document specifies TWO distinct data exchanges for standardization. Below the reader will find 468 one section addressing the Client Tracking Exchange, followed by a second addressing the Client 469 Registry Exchange, each with identical document structures. The Data Dictionary in Section 6, 470 however, provides a reference to all elements contained in both. 471
b. Later in this document, the Client Tracking Exchange and the Client Registry Exchange are broken 472 into their own major section for specification. Each section contains its own introduction, message 473 actors, scenarios and Use Cases, requirements, and specification information. However, common 474 requirements applicable to both are included only once, prior to the breakout of these two specific 475 sections. 476
477 1. Introduction
a. Background b. Purpose c. Outstanding Issues d. Document Structure
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 19
e. Terminology 2. Tracking Exchange for Clients
This Section provides overall context and specifies the scope and traceable requirements which MUST be met in order for the resulting standard to meet the needs of the emergency response and communications, and disaster management practitioners.
a. Message and Actors b. Scenarios and Use Cases
i. Variables ii. Representative Use Case List iii. Use Case “Events and Triggers
c. Requirements (Normative) i. General Requirements ii. Functional Requirements iii. Information Requirements iv. Conformance Requirements
d. Specification Though the final OASIS product will reflect improved and more detailed modeling and definition, this section provides a logical graphic and tabular representation of the standard message requirements, information needs and definitions, attributes (such as cardinality) and relationships.
i. Required Elements Model ii. Detailed Element Reference Model (ERM) iii. Common Elements Model
3. Registry Exchange for Clients
This Section provides overall context and specifies the scope and traceable requirements which MUST be met in order for the resulting standard to meet the needs of the emergency response and communications, and disaster management practitioners.
a. Message and Actors b. Scenarios and Use Cases
i. Variables ii. Representative Use Case List iii. Use Case “Events and Triggers
c. Requirements (Normative) i. General Requirements ii. Functional Requirements iii. Information Requirements iv. Conformance Requirements
d. Specification Though the final OASIS product will reflect improved and more detailed modeling and definition, this section provides a logical graphic and tabular representation of the standard message requirements, information needs and definitions, attributes (such as cardinality) and relationships.
i. Required Elements Model ii. Detailed Element Reference Model (ERM) iii. Common Elements Model
4. TEC Data Dictionary (Normative) 478
479 Appendices 480 Appendices in this document contain a glossary, definition of key terms, and the list of outstanding 481 issues for easy reference. Refer to the appendices contained in the EDXL- TEC PID document for 482 additional background and references. 483
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 20
1.6 Terminology 484
Appendix B provides a glossary of acronyms while Appendix C provides definition of some key terms. 485 This terminology section provides guidance in the development and understanding of TEP requirements 486 statements contained in section 2.5 of this document. 487
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 488 NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 489 in [RFC 2119]. 490
The term “Conditional” as used in this specification is to be interpreted that a message element MUST be 491 used, according to specified rules (elements MUST be one of “Required,” “Optional” or “Conditional”). 492
RFC 2119 specifies: 493
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute 494 requirement of the specification. 495
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute 496 prohibition of the specification. 497
3. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in 498 particular circumstances to ignore a particular item, but the full implications must be understood and 499 carefully weighed before choosing a different course. 500
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid 501 reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full 502 implications should be understood and the case carefully weighed before implementing any behavior 503 described with this label. 504
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may 505 choose to include the item because a particular marketplace requires it or because the vendor feels that it 506 enhances the product while another vendor may omit the same item. An implementation which does not 507 include a particular option MUST be prepared to interoperate with another implementation which does 508 include the option, though perhaps with reduced functionality. In the same vein an implementation which 509 does include a particular option MUST be prepared to interoperate with another implementation which 510 does not include the option (except, of course, for the feature the option provides.) 511
512
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 21
2 EDXL-TEC Process and Compatibility 513
2.1 EDXL-TEC Definition Process 514
Please refer to the EDXL- TEC Project Initiation Document (PID) for a description of the process applied 515 to facilitate development of the EDXL-TEC PID as well as this “Requirements and Draft Messaging 516 Specification” document. 517
2.2 Standards Compatibility 518
The TEC Standard MUST be compatible with the following existing standards, policies or practices. 519 “Compatibility” in this context means that like concepts are represented in the same way, and formats are 520 compatible or can be referenced, e.g. existing managed lists, in order to facilitate broad interoperability 521 and leverage current efforts. 522
The OASIS EDXL family of standards including the EDXL-Distribution Element, Resource 523 Messaging (RM), Hospital AVailability Exchange (HAVE), Common Alerting Protocol (CAP), and 524 the in-process OASIS EDXL-Situation Reporting (SitReps) and Tracking of Emergency Patients 525 (TEP). 526
o The Client tracking components of TEC and TEP MUST be evaluated to determine whether 527 requirements should be satisfied through one data exchange standard or two. 528
o Where decisions are made to address equivalent requirements using methods or elements 529 different from previous EDXL standards, then OASIS must develop and pursue an action plan 530 for new versions of existing standards for consistency with future decisions or trends. 531
NIEM – National Information Exchange Model. The OASIS process SHALL research and re-use 532 NIEM elements where an existing NIEM element precisely meets the requirement. 533
NIMS – National Incident Management System 534
HL-7 – Health Level 7 specifications where applicable to facilitate understanding of the 535 information. 536
Health Insurance Portability and Accountability Act (HIPAA) 537
Health Information Technology for Economic and Clinical Health Act, and Personally Identifiable 538 Information (PII) requirements, such as those cited in the National Institute of Standards and Technology 539 (NIST) Guide to Protecting the Confidentiality of Personally Identifiable Information; as well as other 540 privacy requirements as applicable. 541
2.3 EDXL Message Distribution 542
The primary purpose of this Specification is to provide a standard format for XML-based messages. 543 These Messages are specifically designed as “payloads” which carry information (content), which require 544 a separate standard routing mechanism. 545
This Specification contains requirements for two different specifications, Tracking Exchange and Registry 546 Exchange, which provide different options for message Distribution. 547
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 22
Tracking Exchange message - provides data exchange for tracking Clients who are encountered 548 by emergency response or service provider personnel during an event, from their initial 549 encounter, through transport, sheltering and until they are released from the tracking system 550 upon return to their origin or released. Distribution of this exchange message is satisfied by the 551 EDXL-DE routing message, or equivalent. 552
Registry Exchange message – provides data exchange, where a Client’s information 553 (identification, contact information, location, etc.) is posted to a Registry system to allow other 554 people to locate and determine the condition of missing or displaced person during an emergency 555 event. The Registry Exchange message format, based on the foundation of the People Finder 556 Interchange Format (PFIF), must continue to serve pre-existing mechanisms for posting and 557 exchange of PFIF data among existing Registries, which include the option to use Atom or RSS 558 information feeds to post information or share updates among Registries. In addition, however, 559 the Registry Exchange may also be distributed using the EDXL-DE message routing message 560 with systems or recipients that may require or accept its format for delivery. 561
2.3.1 EDXL Distribution Element (EDXL-DE) 562
EDXL Distribution Element (EDXL-DE) V 1.0 was approved as an OASIS standard in April 2006, and the 563 DE v2.0 is in-development in the OASIS EM-TC, entering the initial public comment phase as of this 564 writing. The EDXL-DE provides a flexible message-distribution framework for data sharing among 565 emergency information systems using XML. The EDXL-DE may be used over any data transmission 566 system, including, but not limited to, the SOAP HTTP binding. 567
The primary purpose of the Distribution Element is to facilitate the routing of emergency messages to 568 recipients, including CAP where applicable. The DE may be thought of as a "container". It provides the 569 information required to route "payload" message sets (such as Alerts, Resource Messages or TEC 570 messages), by including key routing information such as distribution type, geography, incident, and 571 sender/recipient IDs. Messages may be distributed to specific recipients, to a geographic area, or based 572 on codes such as agency type (police, fire, etc.) 573
2.3.2 Exchange Messaging Distribution 574
The EDXL-DE is designed to carry one or more payloads called “Content Objects”. Each Content Object 575 may be well-formed ContentXML or OtherContent – objects such as images or documents. The Tracking 576 Exchange message is designed to be well-formed ContentXML for routing using the EDXL-DE. The 577 EDXL-DE supports both context sensitive routing via metadata (i.e. information about the Content 578 Objects) and directed distribution (i.e. the sender specifies recipients). 579
While the TEC Tracking Exchange is designed to be an EDXL-DE payload, other routing mechanisms 580 may be used to distribute EDXL-TEC content if the message metadata required for this standard is 581 provided in consistent form. 582
The TEC Registry Exchange, based upon the existing People Finder Interchange Format (PFIF) has a 583 specific and unique purpose. This exchange is designed to be a standard format for passing data records 584 used to add or create new records in one or more receiving registry systems, to update existing records in 585 those systems, to delete records, and to specify rules which define whether a particular record may be 586 promulgated beyond the immediate receiving system. Given that the domain of systems targeted to 587 utilize this exchange is very specific, the Registry Exchange may be passed using current methods such 588 as Atom and RSS feeds. 589
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 23
3 Common Technical Requirements 590
591
The following overarching General and Functional Requirements apply to both the TEC Tracking 592 Exchange as well as the TEC Registry Exchange. Requirements specific to the Tracking and Registry 593 Exchanges can be found in their respective sections of this document. 594
3.1 General Requirements 595
General requirements are simply overarching requirements that apply across the TEC messaging 596 standard. 597
Table 1 - TEC General Requirements 598
General Requirements
Rqmt
#
Requirement
1. This Requirements Statement and Draft Messaging Specification for the Tracking of Emergency Clients Messaging Standard (EDXL-TEC), is Part II of a two-part submission to OASIS. Part I of the submission is the Project Initiation Document (PID), which is a mandatory component and prerequisite to the EDXL-TEC Requirements and draft Messaging Specification. All specification details MUST be guided by and fall within the PID context, objectives and scope. Information contained in the PID is not repeated in this specification.
Both the EDXL-TEC Project Initiation Document (PID) and the EDXL-TEC Requirements and draft Messaging Specification MUST be considered in whole without exclusions within the OASIS process. All requirements and concepts captured herein must be supported and the final product (the OASIS public standard) mapped to these requirements and information needs as proof, in order to meet the full intention and requirements of the practitioner community.
2. EDXL messaging - Requirements herein agreed upon by the EDXL Practitioner Steering Group (PSG), Standards Working Group (SWG), extended Stakeholder community for TEC, DHS-OIC and EIC, SHALL be used to develop a public XML-based messaging standard.
3. Functional Areas – TEC MUST support the Functional / Business Process domains of emergency response and disaster management, supporting incident management stages of preparation, response, and management.
Within these incident management stages, TEC through standardized information-sharing MUST support client tracking and emergency business processes across the emergency continuum of care from initial Client Encounter until Client release.
4. All Hazards – TEC MUST support emergency/disaster response & management processes for all types of hazards. For example, facilitate sharing of client tracking in response to a natural disaster, CBRN event, or day to day incident.
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 24
General Requirements
5. Incident scale – TEC MUST support client information-sharing for all hazards of any scale, from local, day to day up to state or federally declared major disasters / mass casualty situations including both planned and unplanned events. A TEC message must be sufficiently “light” to foster day to day usage, by requiring through definition of the minimum number of required elements which meet priority information needs and message / data structure integrity.
6. International focus – TEC MUST support client information-sharing within and across local, tribal, state, federal and non-governmental agencies, private sector organizations, other stakeholders, host nations, and systems providers across the globe.
7. Current systems – TEC MUST facilitate client tracking information-sharing without requiring significant changes to existing or planned systems / database structures which normally perform client tracking functions; through standardized information-sharing between those disparate systems. TEC must enable cross-system send and receive of TEC information between disparate software systems and applications, and enable presentation and processing of that information natively through TEC standard element are mapping to existing system elements.
8. Redundant data entry – TEC SHALL facilitate the minimization or elimination of redundant data entry (“re-keying” of information) for client tracking, with the objective of reducing errors related to manual data entry; maximizing the utilization of emergency response and emergency management resources, and saving invaluable time.
9. EDXL compatibility - Where decisions are made to address requirements that are equivalent to concepts and elements in other current and upcoming EDXL standards, OASIS MUST apply methods which are consistent and compatible with EDXL standards. However, different methods are chosen to pursue future direction or trends, MUST develop and pursue an action plan for new versions of existing standards to ensure consistency and ongoing “interoperability” of use between EDXL standards
10. Support processes for search, people-finding and family re-unification, through access to richer, more complete and consistent information, by sharing data about clients, their location and status across existing private industry, NGO and federal Tracking and “Registry” systems.
599
3.2 Functional Requirements 600
Functional Requirements provide functional capabilities and what the messaging standard must support 601 or accomplish. 602
Table 2 - TEC Functional Requirements 603
Functional Requirements
Rqmt
#
Requirement
1. Requirements met by other EDXL standards - EDXL-TEC requirements and information needs MUST be evaluated to determine where within the EDXL family certain requirements are best addressed (i.e. within the TEC payload, in the EDXL-DE, or elsewhere.
Where it is determined that required information need best fits in the DE, a strategy SHALL be developed and presented to the TEC Steering Committee detailing the timing and approach to
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 25
Functional Requirements
address dependencies.
Specifically for TEC, the OASIS EM-TC SHALL consider use of the following EDXL-DE elements or capabilities in order to satisfy these TEC information requirements. Details are contained in the “Information Requirements” section.
Type / purpose of the message (distributionType)
messageSender (senderID & senderRole)
dateTime message is sent (dateTimeSent)
IncidentType
Ability to share additional XML and non-XML content associated with the TEP message, such as photograph and fingerprints.
2. Reference to code lists and other external information - TEC Tracking Exchange design MUST provide the ability to reference external tables or lists for specifying or referring to certain data or content where appropriate (using ValueListURI / Value)
Examples: IncidentType, AgeUnits, EyeColor and others.
3. Sensitive Information Exchange – The TEC Standard simply specifies a standard format and structure to be used to package data for electronic transmission from a system to one or many other systems. Potential security and privacy concerns do not apply to this standards development effort; nor do they apply to the resulting standard or resulting data exchange structure, since neither deal with actual data values.
To the extent possible or applicable, the EDXL effort will include metadata to assist with privacy and security designation and handling, whether through the payload, or, more likely through the EDXL routing mechanism (the EDXL-Distribution Element).
It is the responsibility of the organizations that are sharing information with outside entities, whether electronic or otherwise, to put in place agreements and policy to address security and privacy concerns, and adhere to applicable Health Insurance Portability and Accountability Act (HIPAA), Health Information Technology for Economic and Clinical Health Act, and Personally Identifiable Information (PII) requirements.
4. TEC Conformance - Specific TEC standard conformance requirements MUST be developed and published in the final OASIS EDXL-TEC standard.
5. EDXL standards re-use and coordination – The EDXL-TEC standard MUST maintain consistency with existing OASIS EDXL standards in the support of equal or equivalent concepts and requirements. Where common concepts and elements are changed or handled in a different way from existing EDXL standards, a specific and well-communicated plan and timeline MUST be developed to maintain EDXL standard consistency and ability to work together.
6. Message Types / specification of multiple messages – All specific message types identified during the requirements process were determined to be met by the EDXL-Distribution Element (EDXL-DE) “DistributionType” values:
a. Report - New information regarding a Client / tracking activity.
b. Update - Updated information superseding a previous message.
c. Cancel - A cancellation or revocation of a previous message.
d. Request - A request for client information.
e. Response - A response to a previous request.
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 26
Functional Requirements
f. Ack - Acknowledgment of receipt of an earlier message.
g. Error - Rejection of an earlier message (for technical reasons).
h. Note for OASIS consideration: How to send a message for deletion of a client? This is likely an implementation issue to be agreed between partners, but could specify a business rule to use an update message containing a past expiration date (do not use “Cancel” message type).
7. TEC message DateTimeSent
A TEC message MUST support the date/time that the TEC message is actually sent.
Since a TEC message MUST be a payload of the EDXL-DE or equivalent routing mechanism, this requirement is met by the EDXL-DE “DateTimeSent” element.
8. TEC message DateTimeExpires
A TEC message MUST support the date/time that the TEC message should expire, which would trigger deletion.
Since a TEC message MUST be a payload of the EDXL-DE or equivalent routing mechanism, this requirement is met by the EDXL-DE “DateTimeExpires” element.
9. Linking of TEC data to Client – TEC MUST maintain structure and necessary identifiers to facilitate receiving systems ability to receive multiple TEC messages about a given client, and associate that data with one unique client, considering the fact that during a mass casualty, one jurisdiction may assign a “unique” identifier, while another jurisdiction (perhaps receiving evacuated clients) may assign a different ID to the same client. TEC MUST have the ability to carry multiple unique identifiers for each client, and carry a minimum set of additional elements to assist personnel and receiving systems unique identification of each client and their associated tracking information.
10. Audit Trail- TEC messages must support a sequence of steps supported by proof documenting the real processing of a transaction flow through an organization, a process or a system
604
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 27
4 Tracking Exchange for Clients 605
4.1 Tracking Exchange Message and Actors 606
The following provides a general definition of the TEC Tracking Exchange for Clients message, and lists 607 typical actors; and general types of senders and receivers of this exchange message. 608
Table 3 – Tracking Exchange Message Definition 609
MESSAGE NAME
MESSAGE DEFINITION SENDERS RECIPIENTS
Tracking Exchange for Clients
The TEC Tracking message is an EDXL message that is intended to facilitate sharing of data about individuals affected or displaced during an emergency. It is aimed at effective evacuation management, and supports coordination and effective use of assets, client "finding” for family reunification, and gaps identified by HHS-AHRQ processes (Dept. of Health and Human Services-Agency for Health and Research Quality). TEC Tracking messages are intended to facilitate tracking, regulation, care and reunification of all affected general population clients, whether they are displaced, evacuated, or sheltering in place. A TEC Tracking message may contain information about the related incident; client identification, associations and relationships; tracking client movements and location; and service providers from first encounter to shelter until release or reunification/repatriation.
Evacuation response personnel
Emergency Management
Shelter management and staff personnel
"Official" Person Queries
Private Sector Locations
Medical facilities providing transient sheltering
Evacuation response personnel
Emergency Management
Shelter management and staff personnel
"Official" Person Queries
Federal, State, International, and Local officials
Private Sector Locations
Medical facilities providing transient sheltering
4.2 Tracking Exchange Scenarios and Use Cases 610
The EDXL standards development process utilizes scenarios and use cases to drive out and/or confirm 611 detailed requirements and message design. A scenario describes a potential incident or set of events 612 and its response, step by step over time. The scenario is used to demonstrate application or typical uses 613 of the Messaging Standard from an end-user perspective. A use case describes a sequence of actions 614 performed by each actor representing some potential uses of the Standard within the scenario. The 615 process drives out requirements and information that needs to be exchanged. Existing documents, forms, 616 and other materials were also used in the development of use cases. 617
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 28
Because of the in-depth past work performed in the area of Client Tracking, the TEC Tracking Exchange 618 analysis effort focused primarily on detailed use cases given that TEC messages must apply to any type 619 of incident or hazard of any scale. 620
TEC is intended purely as a standard to provide electronic information flow, through non-standardized 621 electronic methods, or not provided at all through the client tracking process. Users will create or change 622 data in the field as driven by process, events, and circumstances. Changes are captured and then 623 shared in compliance with the TEC messaging standard according to local standard operating procedures 624 (SOP’s) and implementation decisions. 625
4.2.1 Use Case Variables 626
While not an all-inclusive list, the following variables were considered, tested and built into the use case 627 analysis for TEC to help determine requirements and priorities. 628
Table 4 – Tracking Exchange Use Case Variables 629
VARIABLES VARIABLE TYPES
Event Small-scale, MCI, Planned Event(e.g. Political Convention, International Summit), Technological
Hazard Type Chemical, Radiological Incident, Natural Disaster, Day to Day (Car Accident), Pandemic, Biohazard
Response Single Jurisdiction, Multi-Jurisdictional,
Jurisdiction Local, State, Federal, Tribal, International
Client Origination Self-Present, Embarkation Point, Shelter, Hospital/Definitive Care, Institutional. Debarkation Point
Shelter Type Local, State, Federal, NGO (Red Cross, Faith Based), International
Evacuee Type
General Population, Special Needs, Medical Special Needs, Medical, Vulnerable (Blind/Deaf), Minors, Unaccompanied Minors, Homeless, Substance Abusers, Homebound, Responders who have completed duties, Prisoners, Psychiatric Patients, Others Requiring Supervision, Self-evacuee, Institutional, Veteran, Unidentified Persons (e.g. small children, non-English speaking)
Client Functional Needs
Elderly, Homebound, Minor, Supervision (e.g. Unaccompanied Minors, Substance Abusers, Prisoners, Psychiatric Patients, Sex Offenders, etc.), Service Animal
Jurisdictional Movement Local-Local, State, Federal, Tribal; State- Local, Federal, Tribal; Federal-Local, State, Tribal; Tribal-Local, State, Federal, International
Client Condition Responsive, Unresponsive, Deceased, Alert and Oriented
Transportation Ambulance, Air, Boat, Police/Fire, Private Vehicle, On Foot, Train
Disposition
Disposition includes 2 subcategories “status” and “location” – status “released/discharged” or “transferred” and location “home”, “shelter”, “ED”, “Hospital”, “Dialysis Center”, “nursing home” or “other”.
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 29
VARIABLES VARIABLE TYPES
Initial Client Presentation Area Scene, Shelter, Triage Area, Transportation/Embarkation point, Intermediate Care Facility, Federal Medical Station, Definitive Care, Online
Traveling w/ client Attendants, Pets, Family Members, Guardians, Service Animals, Equipment, Associated Property, Vehicle
630
4.2.2 Representative Use Case List 631
The following scenarios / use cases were used as a basis for development of the EDXL TEC 632 Requirements and draft Messaging design. Though these Use Cases do not fully describe application of 633 the TEC message components, they were used to test the message design to ensure that design 634 supports each Use Case and triggering event. This list provides a representative sample, questioning 635 “what if” this or that occurs…, and represents a sub-set of the total used to analyze and test requirements 636 and draft message design. This list is therefore not intended to provide exhaustive examples of TEC 637 usage, and may not fully reflect actual practices. 638
Table 5 – Tracking Exchange Use Case List 639
UC # USE CASE DESCRIPTION
1 Client self-presents at shelter and checks-in to shelter
Client self-presents at shelter and checks-in to shelter. Entered into tracking system e.g. NMETS Could be high volumes of people, minimal information collected.
1 Client self-presents at embarkation point.
Client self-presents at an embarkation point and is entered into tracking system and transferred to a shelter.
2
Client self-presents at embarkation point with associations.
Client self-presents at embarkation point with family members, luggage, and pets.
3
Client with special needs self-presents at embarkation
point.
Client self-presents at embarkation point. Client has special needs (previously referred to as special medical needs) e.g. requires dialysis three times a week. Client transferred to shelter.
4
Client with functional needs self-presents at embarkation point.
Client self-presents at embarkation point. Client has functional needs e.g. client electrically dependent, in wheelchair, cognitive, etc. Client transferred to shelter.
5
Client with security/supervision needs self-presents at embarkation point
Client with security/supervision needs self-presents at an embarkation point and transferred to shelter. E.g. Unaccompanied minor(s)
6 Client already at shelter assessed as "sick"
Client already at shelter assessed as "sick" by a volunteer who calls EMS. EMS arrives, treats the Client, and transfers to ED
7 A group of clients is evacuated.
Students(minors) are evacuated from a boarding school and are moved to a shelter using school transportation assets
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 30
UC # USE CASE DESCRIPTION
8 Homebound client evacuated to shelter.
Homebound uninjured person evacuated by EMS to a shelter.
9 Emergency responders evacuate.
Emergency responders are ordered to evacuate per evacuation plan/previous instruction.
10
Hospital evacuation. Hospital ordered to evacuate including non-patients. Patients due to be released without transportation are evacuated to shelters
11 Nursing Home evacuation. Nursing Home ordered to evacuate including non-patients.
12 Institutional evacuation with supervision needs.
Rehabilitation clinic for substance abusers order to evacuate. Clients transferred to shelter.
13
“Door to door” client encounters.
National Guard, Search and Rescue teams, police, and fire conduct door to door search for residents who either refused to leave or were unable to self-evacuate. Clients encountered are transferred to shelters.
14
Bus transport clients to different shelters.
Bus arrives at shelter, some clients are able to check-in to shelter but, shelter reaches capacity. Bus takes remaining clients to another shelter.
15 Bus transporting clients breaks down.
Bus in route to a shelter breaks down, buses are dispatched to pick up stranded clients and transport to shelter.
16 Shelter evacuated. Flood waters approach shelter, shelter is evacuated. Shelter
residents are transferred to state run shelter.
17 Client checks out of shelter. Clients who self-presented at shelters, check-out of shelters.
18
Client checks out of shelter and transferred back to point of origin.
Clients who were transported to shelters are transported back to embarkation points.
19
Shelter closes. Because most areas have been declared safe for return, shelter populations are greatly diminished. Many shelters close and remaining shelter populations are consolidated.
640
4.2.3 Use Case Events and Triggers 641
The following list represents “business events”, circumstances, and/or operating procedures which drive 642 creation or change to relevant information, potentially triggering the need for a Tracking Exchange 643 message. This list was derived from further Use Case testing to ensure that this message exchange 644 supports key triggering events, individually or in combination. 645
Table 6 – Tracking Exchange Use Case Events and Triggers” 646
647
KEY EVENTS THAT TRIGGER MESSAGES
DESCRIPTION
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 31
KEY EVENTS THAT TRIGGER MESSAGES
DESCRIPTION
Client Encountered Meeting or contact between a given responder and/or shelter agent and a given client.
Client moved/ transported (physical location tracking)
Client is physically moved from one location, site, or facility to another
Client being transferred to new care provider
Client tracking responsibility is transferred from one care provider to another
Client Released Client released from care and is no longer being tracked using TEC
Client information updated Further identifying or pertinent client information is collected that would assist in meeting client needs.
Time-driven information i.e. transfer to AHRQ National Database
Tracking information is automatically or manually shared with a National Database used for consolidated tracking of patients and clients
Change in conditions requiring client reroute
Change in circumstances requiring client transport to re-route from current destination to a new destination (i.e. receiving facility reaches capacity)
At-risk registration Ongoing registration of "at-risk-individuals"
Client Queries General client queries or queries about client attributes, relationships, or special needs
Data Correction Reorganizing or correcting errors in data
Identification of at-risk individuals
Emergency Services identifies local "at-risk" individuals who may be unable to self-evacuate.
648
4.3 Tracking Exchange Statement of Requirements 649
(Normative) 650
This Section provides overall context and specifies the scope and traceable requirements which MUST 651 be met in order for the resulting standard to meet the needs of the emergency response and 652 communications, and disaster management practitioners. Requirements within each section are 653 numbered to support tracing to the final product. 654
“General Requirements” are overarching. See Section 3 Common Technical Requirements for 655 General Requirements applicable to both the Tracking and Registry Exchanges. 656
“Functional Requirements” are functional capabilities that the messaging standard must support 657 or facilitate. See Section 3 Common Technical Requirements for Functional Requirements 658 applicable to both the Tracking and Registry Exchanges 659
“Information Requirements” define the information needs that the messaging standard must 660 support in terms of elements, relationships or business rules. 661
“Conformance Requirements” define rules that must be followed to guide testing of the 662 standard and implementation conformance. 663
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 32
Though the intent of this section is to comprehensively convey all project requirements textually, the 664 models and data dictionary presented in Section 4.4 and Section 6 provides further clarification and are 665 considered normative. These sections MUST be consulted in concert the Section 4.3, Statement of 666 Requirements in order to ensure a complete understanding of the full requirement (e.g. element 667 definitions). 668
Though requirements and inputs to this standard have been driven out through cross-profession 669 emergency support practitioners based across the U.S., the intent of this effort is to drive an international, 670 public XML-based messaging standard 671
4.3.1 Functional Requirements 672
Functional Requirements provide functional capabilities and what the messaging standard must support 673 or accomplish. Please refer to Section 3.2 for overarching Functional Requirements 674
Table 7 – TEC Tracking Functional Requirements 675
Tracking Exchange Functional Requirements
Rqmt
#
Requirement
1. TEC Routing - EDXL-TEC Tracking MUST be specifically designed as a payload of the OASIS EDXL-Distribution Element, or other routing mechanism used to distribute EDXL-TEC content IF the required routing header metadata is provided in the same form, or if the sender specifies specific recipients of the payload.
2. Client Tracking Business Processes Supported – TEC SHALL facilitate improved capabilities and increased effectiveness of key business processes to support information exchange about general population, or “clients” such as evacuees, those sheltered in place or self-evacuating. Process improvement shall be realized through implementation of TEC standard information-sharing which supports and/or reports on the following Emergency processes and events:
Overall emergency management and cross-organization coordination
Cross-system client tracking and evacuation management whether self-evacuated, sheltered in place, or being transported or assisted, from the time of encounter through final disposition, location or exit from the tracking process, including repatriation.
o Client tracking from/to all “intermediate” facilities and sites (e.g. shelters, transportation points)
Provide the ability to share information over and above a person’s current and planned location. Examples include information such as special needs, property and relationships to other clients.
Support information-sharing that improves matching evacuee needs with available services, transportation, shelters and resources.
Family Notification through sharing of Client identification information
3. Client tracking – TEC Tracking Exchange MUST provide the information required to facilitate tracking the current location of a Client at a point in time. TEC MUST provide location information required to plot Client location and movement on maps and in mapping applications.
4. TEC must also have the ability to associate individual clients such as a family, care-takers, or significant others.
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 33
Tracking Exchange Functional Requirements
5. TEC Must have the ability to associate responders/care providers with a group of clients. Once the responder leaves his/her jurisdiction, they are tracked the same way as clients.
6. An individual is not considered a Client in the context of TEC Tracking until they have been encountered as part of an emergency response.
676
4.3.2 Information Requirements 677
Information Requirements define the information needs that the messaging standard must support in 678 terms of elements, relationships, cardinality (one or many of a given element or group of elements), 679 optionality and business rules. Table 8 below also TEXTUALLY describes the Element Reference Model 680 (ERM) contained in Section 4.4.1.2 of this specification. 681
Textual descriptions of these TEC models may be found by referring to Section 4.3.2, “Information 682 Requirements”. Requirements #7 to #13 describe Information needs in terms of the data elements 683 required. Requirements #14 to #19 describe relationships of the various data within the message 684 structure (represented by lines between blocks). Finally, Requirements #20 to #22 describe information 685 needs in terms of the supporting data elements required. 686
See the data dictionary for detailed element definitions. 687
Table 8 – Tracking Exchange Information Requirements 688
Tracking Exchange Information Requirements
Rqmt
Number
Requirement
1. Client Tracking Information-types
The Tracking Exchange message SHALL facilitate standardized information-sharing about the following types of information (detailed in the ERM and within this Section).
Client unique identification and descriptive information
Basic Incident information describing the incident associated with the Client
Client Service provider (individual and organization)
Client transport (vehicle) used to transport the Client
Tracking of Client and Service Provider encounters and Client physical movements
Tracking of Client transition or transfer between different client care (e.g., shelter) Facilities
Client evaluation, service/care, and disposition information at any point in time.
Client family members, group or associates’ emergency contact information
2. Tracking Exchange (Routing Header) Distribution Types
See Section 3.2 for details of these Common Requirements
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 34
Tracking Exchange Information Requirements
3. Tracking Exchange message DateTimeSent, DateTimeExpires
See Section 3.2 for details of these Common Requirements
4. Attachments (Content Object)
A Tracking Exchange message and / or its routing mechanism must be capable of carrying / attaching other related XML and non-XML content related to the Tracking Exchange client such as:
Photograph - Optional
Fingerprints - Optional
Other XML content - Optional
Note 1 - Since Tracking Exchange MUST be a payload of the EDXL-DE or equivalent routing mechanism, this requirement is met by the EDXL-DE “Content Object”, wherein each DE may carry multiple content objects.
Implementation Note 2 - The “ClientUniqueIDNumber” must be used to uniquely identify the Client associated with each attachment or content object, and the “ClientUniqueIdNumber” should be identical across Service Providers.
5. Routing multiple Tracking Exchange messages
Each EDXL-Distribution Element or equivalent routing header MUST be capable of carrying from one to many Tracking Exchange messages (as the EDXL-DE does today).
Tracking Exchange is intended to be used as a single message structure to meet the requirements specified herein (in contrast to EDXL-Resource Messaging, which specifies multiple message structures). However, where the need or desire exists to route multiple independent Tracking Exchange messages at the same time, this is facilitated using the routing mechanism such as the EDXL-Distribution Element (DE).
6. Tracking Exchange Message Information Needs
The Tracking Exchange message high-level entity is the top-level element which contains information that uniquely identifies and describes a particular Tracking Exchange message. The Tracking Exchange message MUST contain the following elements of information:
Message ID (required) – MUST carry an identifier to uniquely differentiate each Tracking Exchange message. The identifier must include an ID or number.
System ID (optional) – a Tracking Exchange message may optionally carry the identifier of the system or device which acts as the data source, or an individual’s login credentials. This may include, for example, mobile hand-held devices used by practitioners in the field.
7. Situation (Incident) Information Needs
In support of the business processes defined in Functional Requirement #2 in Table 7, the Tracking Exchange MUST carry information associated with or describing the incident related to the Service Provider and Client Encounter. The purpose is to identify and describe the Situation / Incident which may have been associated with, played a role, or contributed to the Client condition, special or functional needs.
The Tracking Exchange MUST contain the following Incident information. See the TEC Data Dictionary for definitions of each element.
IncidentID / Type / Name “paired” data set (required), multiples allowed:
Tracking Exchange MUST allow carrying of multiple sets of incident ID’s, each with the associated type and optionally name, to facilitate the fact that multiple incident ID’s are often
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 35
Tracking Exchange Information Requirements
created for the same incident across professions.
IncidentID (required)
IncidentType (required)
IncidentName (optional)
IncidentStartDateTime (optional)
RelatedIncidentID (optional) – Identifier for a larger incident or disaster associated with the Care Provider / Patient Encounter incident.
IncidentLocation (required) - The location of the situation (incident), with the capability to express location information in a variety of forms including geopolitical (e.g. addresses), geospatial (e.g. lat/long) and as input to maps.
8. Service Provider Information Needs
In support of the business processes defined in Functional Requirement #2 in Table 7, the Tracking Exchange MUST carry information about the Service Provider responsible for servicing and providing care to the Client during an Encounter for a particular period of time at a particular location. A “Service Provider” is defined as a person belonging to a Local, State, Federal, Tribal, private industry, or NGO organization who provides care or a service to a person evacuating an incident location. Such services may be one or more of a variety, which includes: embarkation (rally location), transportation from one location or facility to another, supervisory or support services to a client, or a shelter worker.
The Tracking Exchange MUST contain the following Service Provider information. See the TEC Data Dictionary for definitions of each element.
ServiceOrganizationID (required)
ServiceOrganizationName (required)
ServiceOrganizationState (required)
ServiceOrganizationCountry (required)
ServiceProviderType (required)
ServicePersonnelID (optional)
ServicePersonnelState (optional)
ServicePersonnelCountry (optional)
ServicePersonnelLicenseSource (optional)
ServicePersonnelCertificationLicense (optional)
9. Client Transport Information Needs
In support of the business processes defined in Functional Requirement #2 in Table 7, Tracking Exchange MUST carry information about the Client Transport (Vehicle - land, air and marine) used to transport the Client over a particular period of time. In addition to providing valuable information, this may be used to facilitate physical tracking of the Client through tracking of the actual transport vehicle.
The Tracking Exchange message MUST contain the following Transport information. See the TEC Data Dictionary for definitions of each element.
UnitNumber (required if transport information is send or received)
VehicleType (optional)
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 36
Tracking Exchange Information Requirements
VehicleOrganization (required)
UnitContactPhone (optional)
Current Location (optional)
NumberOnBoard (optional)
VehicleState (optional)
10. Client Information Needs
In support of the business processes defined in Functional Requirement #2 in Table 7, the Tracking Exchange message MUST carry information about and uniquely identifying the Client encountered during an incident. A “Client” a person of the general population who is impacted by an incident and who is displaced, evacuated, sheltering in place, expired, and/or requiring shelter or medical attention.
A Tracking Exchange MUST uniquely identify a Client regardless of condition or available information in order to associate a record of condition and service care, and to facilitate physical tracking of Client transport/movement, time of arrival forecast for receiving facilities, and to assist search and retrieval of an existing Client information. Client information may also facilitate family notification and reunification by sharing information about the Client identification along with closest relative / guardian or associate emergency contact information.
In a Tracking Exchange message, client information can range from minimal information required to identify and track a Client, to a more complete set of elements allowing unique identification of the person.
The Tracking Exchange MUST contain the following Client information. See the TEC Data Dictionary for definitions of each element.
Client Identification “paired” data set, allow multiples.
– ClientUniqueID (required)
– ClientUniqueIDSource (required)
Note:
a) One unique client ID number is desirable for use across all Service Providers in order to support desired objectives. However, during a mass casualty, one jurisdiction may assign a “unique” identifier, while another jurisdiction (perhaps receiving evacuated clients) may assign a different ID to the same client. A Tracking Exchange MUST have the ability to carry multiple client identifiers for each client, each with the “source” or originator of that ID to assist personnel and receiving systems unique identification of each client and their associated tracking information.
b) The OASIS process SHALL recommend a standard format for this unique ID and specify as a default (not required) format. It is recommended that the format begin or be prefixed with a location or agency code identifying the location or organization source (who, what or where) that created the client's unique identification number.
Gender (required) – added value for “unknown”. See data dictionary
Age (required) – may be estimated. See data dictionary.
AgeUnits (required)
RaceEthnicity (optional)
DateOfBirth (optional)
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 37
Tracking Exchange Information Requirements
PlaceOfBirth (optional)
Personal Identification “paired” data set, allow multiples:
– PersonalIDType (optional)
– PersonalIDNumber (optional)
HairColor (optional)
EyeColor (optional)
DistinguisingMarks (optional)
PrimarySpokenLanguage (optional)
OtherSpokenLanguage (optional, allow multiples)
Veteran (optional)
FunctionalNeeds (optional, allow multiple)
Allergies (optional, allow multiples)
CurrentMedications (optional, allow multiples)
SupervisionNeedsKind (optional, allow multiples)
SecuritySupervisionNeeds (optional)
Reunification Information “paired” data set
– ReunificationCodeID (optional)
– ReunificationCodeDescription (optional)
ClientEvacuationStatus (optional)
ClientContactInformation (optional)
ClosestRelativeGuardianContactInformation (optional)
ClientAssociations (optional)
ClientInfoAccess (optional)
11. Client Encounter Information Needs
In support of the business processes defined in Functional Requirement #2 in Table 7, the Tracking Exchange MUST carry information about each encounter between each Service Provider and a Client. An “encounter” is defined as the first or initial meeting or contact between a given Service Provider and a given Client; and each subsequent interaction with the same or different service personnel. The Tracking Exchange message MUST contain the following Encounter information. See the TEC Data Dictionary for definitions of each element.
EncounterID (required)
EncounterDateTime (required)
EncounterLocation (required)
MessageForFamilyAndFriends (optional)
LocationCategory (required)
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 38
Tracking Exchange Information Requirements
12. Client Transfer Information Needs
In support of the business processes defined in Functional Requirement #2 in Table 7, the Tracking Exchange message MUST carry information about a Client Transfer if one occurs. “Transfer” is a set of information collected about Client movement from one physical location or care facility to another, and/or between one Care Provider and another over the course of emergency treatment and transport. The TEC Standard MUST contain the following Transfer information. See the TEC Data Dictionary for definitions of each element.
DestinationTransferredToETA (optional)
TransferredToDestination (required)
ActualDepartureDateTime (optional)
ActualArrivalDateTime (optional)
13. Client Service Information Needs
In support of the business processes defined in Functional Requirement #2 in Table 7, the Tracking Exchange message MUST carry information about Client Service at any point in time where these observations or services are performed. Client Service is defined as information observed or service provided for a Client at a point in time; such as evacuating at an embarkation point, sheltering or receiving a service in a shelter where a shelter staff may provide for functional or special needs.
Each Client Service engagement MUST be differentiated by a unique identifier, and a DateTime is required in order to identify when the service was provided, and to associate the DateTime with the service element values that were recorded or performed. Certain elements require an associated DateTime in order for those elements to be accurately interpreted or to be valid.
The Tracking Exchange message MUST contain the following minimum set of Client Service elements. See the TEC Data Dictionary for definitions of each element.
ClientServiceRecordID (required)
ClientServiceRecordDateTime (required) Date and Time this entire Client Service record was recorded. Acts as the unique ID for the Client Service record.
NOTE: This is to avoid capture of a DateTime for each and every instance of a care element.
ClientServiceNeeded (optional)
ClientServicePerformed (optional)
ClientCurrentDisposition (required)
14. Tracking Exchange message relationships: Incident, Service Provider and Client
The Tracking Exchange design MUST enforce the following information relationships for each message, as represented in the Element Reference Model (ERM):
Each Tracking Exchange message represents one and only one Incident, one and only one Service Provider, and one and only one Client associated with that incident and being served by that Service Provider.
15. Tracking Exchange message relationships: Client Encounter
The Tracking Exchange message design MUST enforce the following information relationships for each Tracking Exchange message, as represented in the Element Reference
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 39
Tracking Exchange Information Requirements
Model (ERM):
One and only one Client Encounter MUST exist for each Client and Service Provider in a given message. An “encounter” is defined as the first or initial meeting or contact between a given Service Provider and a given Client. A Client may experience many Encounters during the course of an incident but each Encounter requires a new Tracking message.
Client Tracking messages sent by the same Service Provider about the same Client MUST use the same Client Encounter ID to share information about subsequent Client Service or Transfers to facilitate end to end tracking objectives.
Additional interactions between a Service Provider and Client during the same encounter are captured through the Client Service record; otherwise additional encounters require a new Tracking message.
Multiple independent messages may be sent against the same Service provider / Client to report Services provided. This does not require a new “encounter”.
Conversely, the same Tracking message would never be sent by multiple Service Providers. One Service Provider MUST be associated with (responsible for) one Client at any point in time.
16. Tracking Exchange message relationships: Client Encounter and Client Service record
The Tracking Exchange message design MUST enforce the following information relationships for each Tracking Exchange message, as represented in the Element Reference Model (ERM):
Each Encounter between a Client and Service Provider within one incident, in one Tracking Exchange message MUST contain one or more Client Service records. A Client Service record is defined as a set of information, observations, or services needed or provided for a Client at a point in time. A Service Provider may provide multiple services for a Client to be included in a given Tracking Exchange message and/or as a result of a given Encounter. Each message may record or update information about services needed or performed.
This facilitates advance preparation by Service Providers who may later encounter the Client in the chain of services provided for the Client. It may also support Shelters and other Service facilities to prepare space, resources and services for the incoming Client.
17. Tracking Exchange message relationships: Client Encounter and Transport
The Tracking Exchange Standard design MUST enforce the following information relationships for each Tracking Exchange message, as represented in the Element Reference Model (ERM):
For a given Client Tracking message, each Client Encounter is associated with one and only one mode of Transport (vehicles - land, air and marine) used to transport this specific Client as a result of this Encounter when a Client Transfer has occurred.
Note:
The TEC Tracking Exchange message relationship between Client Encounter and Transport represents a different relationship than exists for Tracking of Emergency Patients (TEP) in the following way: In TEP a Patient and responding EMS personnel continuously attend and accompany the Patient until the Patient is transferred to another Emergency medical care professional in the Field or the Patient is delivered to a Hospital for care.
In TEC, Clients (evacuees) may be assigned to transportation as a result of an encounter as part of an individual, a small or large group, which may include many individuals (for example a mass evacuation from a embarkation location using buses to transport hundreds or even
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 40
Tracking Exchange Information Requirements
thousands to a safe shelter location). In this situation, the Clients are associated (assigned to) appropriate transportation as a result of the Encounter, rather than being assigned to a care provider, who also ‘belongs’ with the unit of transportation (e.g, an ambulance).
18. Tracking Exchange message relationships: “New Message” Requirements
The Tracking Exchange message design MUST enforce the following information relationships for each Tracking Exchange message, as represented in the Element Reference Model (ERM):
As stated in Information Requirement #11, each Tracking Exchange message may contain one or more Client Service records. An Encounter represents
– the initial contact between a Service Provider and a Client
– New Service provider (e.g. Client transfer)
– New Client
A new / different Tracking Exchange message MUST be created whenever:
Any new Client Encounter occurs. Multiple independent messages may be sent against the same Service provider / Client over time, which does not require a new “encounter”. A new Client is encountered, or an existing Client is encountered by a new Service Provider. In this context, “new” implies new to a Client Tracking process, and “existing” refers to a Client that is known to a Client Tracking process (i.e. a Tracking Exchange message has been sent).
A different Situation (incident) applies
The current Tracking Exchange message about that Client has been already been sent
19. Tracking Exchange message relationships: Client Transfer
The Tracking Exchange message design MUST enforce the following information relationships for each Tracking Exchange message, as represented in the Element Reference Model (ERM):
A Tracking Exchange message MUST capture multiple Client physical moves or changes in Service provider in such a way that a single Tracking Exchange message can carry information for multiple physical moves or Service Provider changes. One scenario or example is applied where no connectivity exists, or other circumstances which allow capture of multiple “transfers”, but the Tracking Exchange message is not sent until a later time.
Each Encounter between a Client and Service Provider within one incident in one Tracking Exchange message MUST contain zero or more “Transfers”. A “Transfer” is defined as a set of information collected about Client movement from one physical location to another, and/or between one Service Provider and another. This means a given Tracking Exchange message may contain no transfer data, may contain one transfer, or may contain multiple transfers that may have occurred before a Tracking Exchange message was sent.
No Transfer occurs when a Client is immediately “released” by the initial Service Provider (i.e. released and allowed to leave). In this scenario a final Client disposition would be posted.
20. Supporting Elements: Contact Information
Supporting elements MUST be utilized and reused across Tracking Exchange message elements. Tracking Exchange message Contact information MUST be utilized in a manner consistent with current OASIS EDXL Standards or a specific and well-communicated plan and
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 41
Tracking Exchange Information Requirements
timeline developed to keep EDXL standards in synch for common concepts and elements.
Tracking Exchange message Contact structures MUST be utilized to support the following elements:
ClientContactInformation
ClosestRelativeGuardianContactInformation
Tracking Exchange Message sender ContactInformation (SenderID)
Supporting contact information SHALL include, but may not be limited to the following:
LastName
FirstName
MiddleInitial
ContactLocation
– StreetAddress
– City
– State
– Zip
– County
– Country
ContactNumbers (ex:
– TelephoneNumber
– CellPhoneNumber)
ElectronicAddressIdentifiers (ex:
– Email addresses, Chat, Skype, Twitter, etc.)
21. Supporting Elements: Location Information
Supporting elements MUST be utilized and reused across Tracking Exchange message elements. The Tracking Exchange message MUST provide flexible options to specify locations anywhere in the country or in the world. Location elements must be sufficient to support geopolitical and geospatial designations, and to support receiving system mapping applications and GPS tracking capabilities.
Tracking Exchange message Location information MUST be utilized in a manner consistent with current OASIS EDXL Standards or a specific and well-communicated plan and timeline developed to keep EDXL standards in synch for common concepts and elements.
Tracking Exchange Location structures MUST be provide Location information using EDXLLocation from the EDXL Common Types standard which offers two forms:
EDXLGeoPoliticalLocation
This form of Location includes the following elements:
– StreetAddress
– City
– State
– Zip
– County
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 42
Tracking Exchange Information Requirements
– Country
– LegalDescription
– LocalName
OR
Location may be identified as a geocoded location using a commonly accepted name, such as New Orleans SuperDome, Rochester Community Center, Richmond City Hall, etc..
EDXLGeoLocation
This form provides a geographic location using a standard form for latitude and longitude coordinates in accordance with EDXL GML Simple Features standard. EDXLGeoLocation may be provided in one of the following GML Simple Features forms:
– Point
– CircleByCenterPoint
– Polygon
– Envelope
– LineString
22. Supporting Elements: Value Lists
Supporting elements MUST be utilized and reused across Tracking Exchange message elements. Value Lists with values MUST be utilized consistently with existing OASIS EDXL Standards to provide a flexible approach to provision of managed lists of codes and other data selections. The following forms of Value Lists may be used. For situations that allow multiple values to be included from a given Value List then ValueListType shall be used; where only one value is allowed to be selected from a given Value List then the ValueKeyType shall be used:
ValueListType which includes:
– ValueListURI: xsd:AnyURI
– Value: xsdString [1..*]
ValueKeyType which includes:
– ValueListURI (xsd:anyURI)
– Value (xsd:string)
This approach SHALL be used or considered with any element where a standardized managed list of options meets the stated requirement, such as:
Gender
RaceEthnicity
AgeUnits
PersonalIDType
HairColor
EyeColor
PrimarySpokenLanguage
OtherSpokenLanguage
FunctionalNeeds
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 43
Tracking Exchange Information Requirements
Vulnerability
SpecialNeeds
Allergies
CurrentMedications
SupervisionNeedsKind
ClientAssociations
IncidentType
ServiceOrganizationState
ServiceProviderType
ServicePersonnelState
ServicePersonnelCertificationLicense
VehicleType
VehicleState
LocationCategory
ClientServiceNeeded
ClientServicePerformed
ClientCurrentDisposition
Location:City
Location:State
Location:Zip
Location:County
Location:Country
Location:LegalDescription
Location:LocalName
ContactInformation:City
ContactInformation:State
ContactInformation:Zip
ContactInformation:County
ContactInformation:Country
689
4.3.3 Conformance Requirements 690
Tracking Exchange Message Conformance Requirements are shown below: 691
A Tracking Exchange Message Constraint Schema or Profile MUST not become a new or additional 692 messaging “standard” (another Tracking Exchange Message “version”). It is simply a more 693 constrained version of an existing messaging standard. 694
A Tracking Exchange Message Constraint Schema or Profile message MUST comply with the 695 OASIS Tracking Exchange Message standard. 696
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 44
A Tracking Exchange Message Constraint Schema or Profile message MUST always validate 697 against the OASIS Tracking Exchange Message standard Schema. 698
A Tracking Exchange Message Constraint Schema or Profile message MUST validate within the 699 OASIS Tracking Exchange Message standard namespace with no changes to root elements. 700
A Tracking Exchange Message Constraint Schema or Profile message MUST use all required 701 elements (i.e., no deletion of required elements are allowed). 702
A Tracking Exchange Message Constraint Schema or Profile message MUST not change attributes 703 for required fields. 704
A Tracking Exchange Message Constraint Schema or Profile / message MUST NOT be a 705 Proprietary Format. 706
A Tracking Exchange Message Constraint Schema or Profile message MAY further constrain the 707 Tracking Exchange Message standard.* 708 (* may be thought of as a “constraint Schema” against the standard) 709
A Tracking Exchange Message Constraint Schema or Profile message MAY add to required element 710 definitions.* 711 (* only to extend or interpret the definition) 712
A Tracking Exchange Message Constraint Schema or Profile message MAY limit the size of required 713 elements. 714
A Tracking Exchange Message Constraint Schema or Profile message MAY exclude optional 715 elements. 716
4.4 Tracking Exchange Draft Message Specification 717
Though the final OASIS product will reflect improved and more detailed modeling and definition, this 718 section provides a logical graphic and tabular representation of the standard message requirements, 719 information needs and definitions, attributes (such as cardinality) and relationships. 720
This section MUST be considered in whole with the requirements and rest of the document within the 721 OASIS process, and is organized into the following major sections. 722
Tracking Exchange Message Distribution 723
Tracking Exchange Message “Required Elements” Model 724
Tracking Exchange Message Element Reference Model (ERM) 725
Tracking Exchange Message Common Elements Model 726
4.4.1 Tracking Exchange Message Structure (Normative Unless 727
Otherwise Stated) 728
This section of the document is normative unless otherwise stated. If any differences are found between 729 the models and the data dictionary, then the data dictionary shall always take precedence and the other 730 artifact(s) must be changed to match the data dictionary. 731
This draft messaging specification and resulting schema provides an overall element reference schema, 732 used either in whole or applying constraint schemas during implementation. A constraint schema is 733 simply a subset of the standard reference schema which conforms to all the requirements and business 734 rules of the reference schema. For example, an implementation of the standard may eliminate selected 735 optional elements, or enhance the definition of a required element. 736
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 45
The message structure and data dictionary is defined using successively more detailed or constrained 737 artifacts in the form of diagrams, figures and tables. The purpose of the diagrams is to highlight the 738 structure of the framework and the relationships between the main blocks / entities and their elements 739 (represented as lines on the diagram). Models and data dictionary taxonomies reflect practitioner terms, 740 rules and requirements, and should reflect and agree with Section 4.3 Statement of Requirements 741 (Normative)”. 742
The logical structure of the message is presented using three standard models. With the Data Dictionary 743 this provides an overall definition of the practitioner requirements in the form of message structure 744 (element cardinality), message element definitions and cardinality which must be adhered to. 745 “Cardinality” defines the number of possible occurrences of a given element (ex., a person may have 746 many “personalIdentificationTypes” such as drivers license and passport), or how groups of elements link 747 to one another (each Client may have multiple care records). 748
Required Elements Model – The Tracking Message is first represented in a basic model which 749 reflects only the required or conditional elements. This provides a snapshot of the minimum 750 elements required to send or receive a message through entry or defaulting of known information. 751
Element Reference Model (ERM) – The ERM provides a full model which represents a complete 752 message with all required and optional elements. This is the main structure from which 753 individual constraint schemas (individual reports/message types) may be defined and routed 754 utilizing the EDXL-DE or equivalent routing mechanism. 755
Supporting Elements Model - Finally, elements which are used in common / repeatedly in support 756 of various sections of a message are represented in the Supporting Elements model. Here and in 757 the data dictionary, these elements are defined once for re-use where needed, including 758 Location, Contact and ValueList (code list) information. 759
Boxes on the diagram (“entities”) are used to define message structure by grouping related message 760 elements / tags and defining relationships between blocks of information (represented by lines on the 761 diagrams). 762
Textual descriptions of these message models may be found by referring to Section 4.3.2, “Information 763 Requirements”. Requirements #8 to #15 describe Information needs in terms of the data elements 764 required. Requirements #16 to #21 describe relationships of the various data within the message 765 structure (represented by lines between blocks). Finally, Requirements #22 to #24 describe information 766 needs in terms of the supporting data elements required. 767
Section 5 - Data Dictionary provides definitions of each component group of element and each element 768 within these models. 769
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 46
The following key should be referenced in order to read each of these models. 770
Model KEY:
Each block connected by lines denotes a block of information containing one or more elements which belong to / describe that block (e.g. as one or more attributes describe an Entity in an Entity Relationship Diagram (ERD)).
A dashed-line block indicates required elements / capability, but not being defined within the
scope of the diagram or this TEC standard
The “diamond” end of a line is drawn from a block to the “sub-elements” that belong to or describe that block. The “diamond” end block is above in the hierarchy (the “parent”); thus the connected block is “associated with” or “belongs to” that higher level block.
Lines between blocks (i.e. cardinality / number of occurrences of a group of elements) are read as follows:
One and only one
Zero or one
One or many
Zero or Many
( c ) following an element designates a “Conditional” element (vs. Required or Optional)
On the full Tracking Exchange Element Reference Model (ERM), bold element names are either required or Conditional. Non-bold elements are optional NOTE that the diagram in 3.3.1 shows required elements ONLY, and therefore are not bolded.
Underlined elements indicate reference to supporting elements being reused
An asterisk (*) next to an element designates the element may be used multiple times (i.e. element cardinality – multiple occurrences vs. only one)
771
4.4.1.1 Tracking Exchange Message Required Elements Model 772
The following reflects the basic model showing ONLY the required and conditional elements, providing 773 a snapshot of the minimum elements required for sending or receiving a Tracking Exchange message. It 774 is important to note that careful consideration was given when determining the balance of minimum 775 elements required for a valid and valuable message, vs. the ability and burden in the field to capture this 776 information; too many required elements could present a potential obstacle to adoption. Field 777 professionals felt that many of the elements may be defaulted with known values in implementation prior 778 to use; thus further easing the field burden of data capture and sharing. 779
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 47
780
Figure 3 – Tracking Exchange Message – Required Elements Model 781
4.4.1.2 Tracking Exchange Message Detailed Element Reference Model (ERM) 782
The ERM represents a detailed view of the logical structure of Tracking Exchange Message. The 783 purpose of the ERM is to highlight the more detailed structure of the framework and the relationships 784 between the main entities and their elements. With the Data Dictionary this provides an overall definition 785
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 48
of the practitioner requirements in the form of message structure (element cardinality), message element 786 definitions and cardinality which must be adhered to. This model shows required elements in bold. 787
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 49
788
Figure 4 – Client Tracking Message – Element Reference Model (ERM) 789
4.4.1.3 Tracking Exchange Message Common Elements Model 790
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 50
“Supporting Elements” are re-usable elements that apply to and support multiple areas of the messages, 791 for example Locations, Contacts and Roles, and Unit of Measure. Reference to these re-usable elements 792 are noted in the main diagrams, with the details of each contained in the “Supporting Elements” diagram. 793
794
795
Figure 5 – Client Tracking Supporting Elements 796
797 In addition to the Supporting Elements show above, the Client Tracking ERM uses Value Lists to define 798 commonly used values for some elements in the model. The following diagram provides a list of 799 candidate elements that would each use a Value List. 800
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 51
801
Figure 6 – Client Tracking Exchange Candidate Value List Elements 802
803
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 52
5 Registry Exchange for Clients 804
5.1 Registry Exchange Message and Actors 805
The following provides a general definition of the Registry Exchange for Clients message, and lists typical 806 actors; and general types of senders and receivers of this exchange message. 807
Table 9 – Registry Exchange Message Definition 808
MESSAGE NAME
MESSAGE DEFINITION SENDERS RECIPIENTS
Registry Exchange for Clients
The TEC Registry message is an EDXL message that is intended to facilitate sharing of information about individuals affected or displaced during an emergency. It is aimed at increasing the effectiveness of people finding applications, family reunification, and family notification. The TEC Registry Exchange message is based on the widely adopted People Finder Interchange Format (PFIF)
Evacuation response personnel
Emergency Management
Transportation service personnel
Shelter management and staff personnel
- Clients who self-register
- Users who are searching for clients
- News organizations
- Police agencies
- Person-finding websites
Evacuation response personnel
Emergency Management
Shelter management and staff personnel
Others who may forward a message to others.
- Clients who self-register
- Users who are searching for clients
- News organizations
- Police agencies
- Person-finding websites
5.2 Registry Exchange Scenarios and Use Cases 809
The EDXL standards development process utilizes scenarios and use cases to drive out and/or confirm 810 detailed requirements and message design. The scenario is used to demonstrate application or typical 811 uses of the Messaging Standard from an end-user perspective. A use case describes a sequence of 812 actions performed by each actor representing some potential uses of the Standard within the scenario. 813 The process drives out requirements and information that needs to be exchanged. Existing documents, 814 forms, and other materials were also used in the development of use cases. 815
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 53
5.2.1 Representative Use Case List 816
The following scenarios / use cases were used as a basis for development of the EDXL TEC 817 Requirements and draft Messaging design. Though these Use Cases do not fully describe application of 818 the TEC Registry message components, they were used to test the message design to ensure that 819 design supports each Use Case and triggering event. This list provides a representative sample, 820 questioning “what if” this or that occurs, and represents a sub-set of the total used to analyze and test 821 requirements and draft message design. This list is therefore not intended to provide exhaustive 822 examples of TEC usage, and may not fully reflect actual practices 823
Table 10 – Registry Exchange Use Case List 824
UC # SCENARIO / USE CASE DESCRIPTION
1 Client self-evacuates Client self-evacuates to a family members house outside of the affected area and registers in online registry system e.g. Google Person Finder
2 Client shelters in place Person chooses not to evacuate, shelters in place, and registers in online registry system
3 Client self-evacuates to shelter
Client self presents at shelter and checks-in to shelter and is entered into registry system e.g. family links
4 Client changes location. Client who has already registered in registry system leaves shelter and goes to stay with family. Updates current location in registry system.
5 Client registers in multiple registry systems.
A client may voluntarily register in multiple registry system.
6 Client registers in one system, updates to person record made in another system.
A client registers in registry “A”, their information is propagated to registry “B”. Based on newly available information, the client’s information is updated in registry “B” and propagated back to registry “A”.
7 Missing Person Reported Person is reported missing and entered into a given registry systems with a status of “Missing”
8 Missing Person Found A missing person that has been entered into a registry system is found and the status of the person is updated to “Found”.
5.2.2 Use Case Events and Triggers 825
The following list represents “business events”, circumstances, and/or operating procedures which drive 826 creation or change to relevant information, potentially triggering the need for a Registry Exchange 827 message. This list was derived from further Use Case testing to ensure that this message exchange 828 supports key triggering events, individually or in combination. 829
Table 11 –Registry Exchange Use Case Events and Triggers 830
KEY EVENTS THAT TRIGGER MESSAGES
DESCRIPTION
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 54
Client Registers Client registers in online registry.
Client moved/ transported (physical location tracking)
Client updates location information in online registry.
Client Reported Missing A client is reported missing to an online registry.
Client being transferred to new Service provider
Client tracking responsibility is transferred from one Service provider to another
Client Released Client released from shelter and returns to point of origin
Client Status Changes Missing person has been contacted or author receives information confirming client status.
831
5.3 Registry Exchange Statement of Requirements 832
(Normative) 833
This Section provides overall context and specifies the scope and traceable requirements which MUST 834 be met in order for the resulting standard to meet the needs of the emergency response and 835 communications, and disaster management practitioners. Requirements within each section are 836 numbered to support tracing to the final product. 837
“General Requirements” are overarching. See Section 3.1 for Common General Requirements. 838
“Functional Requirements” are functional capabilities that the messaging standard must support 839 or facilitate. 840
“Information Requirements” define the information needs that the messaging standard must 841 support in terms of elements, relationships or business rules. 842
“Conformance Requirements” define rules that must be followed to guide testing of the 843 standard and implementation conformance. 844
Though the intent of this section is to comprehensively convey all project requirements textually, the 845 models and data dictionary presented in Section 5.4 and Section 6, respectively, provides further 846 clarification and are considered normative. These sections MUST be consulted in concert the Statement 847 of Requirements in order to ensure a complete understanding of the full requirement (e.g. element 848 definitions). 849
Though requirements and inputs to this standard have been driven out through cross-profession 850 emergency support practitioners based across the U.S., the intent of this effort is to drive an international, 851 public XML-based messaging standard 852
5.3.1 General Requirement 853
People Finder Interchange Format (PFIF) Version 1.4 or the most current version of PFIF should be 854 utilized in the development of this standard. Due to the timing of the release of PFIF v 1.4 and the 855 submission of these requirements, PFIF v 1.3 was used to develop the current requirements. 856
857
858
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 55
5.3.2 Functional Requirements 859
860
Functional Requirements provide functional capabilities and what the messaging standard must support 861 or accomplish. 862
Table 12 – Registry Exchange Functional Requirements 863
Registry Exchange Functional Requirements
Rqmt
#
Requirement
1 DE Routing - TEC Registry Exchange MUST be designed in a way that allows a Registry Exchange to be carried payload of the OASIS EDXL-Distribution Element, or other routing mechanism used to distribute EDXL-TEC content IF the required routing header metadata is provided in the same form, or if the sender specifies specific recipients of the payload.
2 Atom Feeds- TEC Registry Exchange MUST be compatible with Atom Syndication format. When utilizing Atom feeds, the Registry Exchange document MUST be embedded using an XML namespace and inserted as an immediate child of the entry element. Atom 1.0 defines a top-level feed element that contains any number of entry elements. The top-level element MUST declare the PFIF namespace.
3 RSS Feeds- TEC Registry Exchange MUST be compatible with RSS feeds that allow publishers to broadcast content automatically.
4 Registry Exchange XML documents can be embedded into RSS 2.0 feeds. (In RSS 2.0 terminology, this section defines an RSS 2.0 module.) The Registry Exchange document should be specified using an XML namespace and embedded as an immediate child of the item element.
RSS 2.0 defines two main elements, channel and item, that are enclosed in a top-level RSS element. The top-level element MUST declare the PFIF namespace.
5 Repositories or Source Systems must be identified by a unique name/URL.
6 Source records can only be updated on source systems. Only NOTE records may be added outside of the source system where the PERSON record originated.
Each record belongs to an original repository, which is the (PFIF or non-PFIF) repository where the record was first entered. The record may be copied to other places, but the original repository remains the authority on the record. Only the original repository should ever change the contents of a record
7 Data should be traceable. Since data comes from sources of unknown reliability and accountability, information on the origins of data should be maintained, to help users ascertain its trustworthiness
8 Because multiple records might refer to the same person, TEC Registry Exchange must allow such records to be associated with each other.
9 Handle international names and name formats
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 56
Registry Exchange Functional Requirements
10 Handle multiple (alternate) names for one person
11 Handle international addresses and address formats
12 Provide ways to contact the client (e-mail, phone)
13 Provide a link or links to personal webpages for the client (blog, journal, social network profile, etc.
14 Specify when the record should be deleted (in order to protect privacy)
15 Allow identifying photographs to be attached or included
16 Support a mechanism to contact the author of the record to clarify or verify information
17 Provide a link to a relevant webpage for a given record, if one exists
18 Enable updates to be posted in one repository about a record in a different repository
19 Specify whether a record can be exported to other repositories
20 Specify when a record should no longer be published/exported (in order to protect privacy)
864
5.3.3 Information Requirements 865
Information Requirements define the information needs that the messaging standard must support in 866 terms of elements, relationships, cardinality (one or many of a given element or group of elements), 867 optionality and business rules. Table 13 below also TEXTUALLY describes the Element Reference 868 Model (ERM) contained in Section 5.4.1.2 of this specification. 869
Textual descriptions of these TEC models may be found by referring to Section 5.3.3, “Information 870 Requirements”. Requirements #15 to #18 describe Information needs in terms of the data elements 871 required. Requirements #19 and #20 describe relationships of the various data within the message 872 structure (represented by lines between blocks 873
See the data dictionary for detailed element definitions. 874
Table 13 – Registry Exchange Information Requirements 875
Registry Exchange Information Requirements
Rqmt
Number Requirement
1 Client Registry Information types
The Client Registry Exchange message SHALL facilitate standardized information sharing about the following types of information (detailed in the ERM and within this Section).
Client information – provides a unique client identification and client identification source in order to relate a evacuee client with a registry client.
Person Record metadata - provides information associated with the client in a registry
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 57
Registry Exchange Information Requirements
such as entry date, expiry date, author’s name, email and phone number, and other source and distribution information.
Person Information – provides information about a person entered in a registry (name, age, gender, etc.)
Note Record information – provides additional information entered over time about a person in the registry, such as to link person records about the same person entered independently in a different registry or the same registry to assist in searches to locate a person.
Status Information – provides information about a person who has been found or reported missing, their location or other pertinent information that might be useful to help in search
DE Routing Information Requirements follow:
2 Client Registry Exchange DE (Routing Header) Distribution Types
See Section 3.2 for details on these Common Requirements
3 DE Message Sender
The Client Registry Exchange MUST carry the actual sender of the message / payload.
Client Registry Exchange message will be routed by the EDXL-DE or equivalent; therefore the “Message Sender” requirement MUST be met using the DE or equivalent where applicable:
EDXL-DE “SenderID” (required)
EDXL-DE “SenderRole” (optional)
Note: See also “SystemID”
4 Client Registry Exchange DE message DateTimeSent
A Client Registry Exchange message MUST support the date/time that the Client Registry Exchange message is actually sent.
Since a Client Registry Exchange MUST be a payload of the EDXL-DE or equivalent routing mechanism, this requirement is met by the EDXL-DE “DateTimeSent” element.
5 Client Registry Exchange DE message DateTimeExpires
A Client Registry Exchange message MUST support the date/time that the Client Registry Exchange message should expire.
Since a Client Registry Exchange MUST be a payload of the EDXL-DE or equivalent routing mechanism, this requirement is met by the EDXL-DE “DateTimeExpires” element.
6 DE (or equivalent) Attachments (Content Object)
A Client Registry Exchange message and / or its routing mechanism MUST be capable of carrying / attaching other related XML and non-XML content related to the Client Registry Exchange client such as:
Photograph - Optional
Fingerprints - Optional
Other XML content - Optional
Note 1 - Since Client Registry Exchange MUST be a payload of the EDXL-DE or equivalent routing mechanism, this requirement is met by the EDXL-DE “Content Object”, wherein each DE may carry multiple content objects.
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 58
Registry Exchange Information Requirements
7 DE (or equivalent) Routing multiple Client Registry Exchange messages
Each EDXL-Distribution Element or equivalent routing header MUST be capable of carrying from one to many Client Registry Exchange messages (as the EDXL-DE does today).
Client Registry Exchange is intended to be used as a single message structure to meet the requirements specified herein (in contrast to EDXL-Resource Messaging, which specifies multiple message structures). However, where the need or desire exists to route multiple independent Client Registry Exchange messages at the same time, this is facilitated using the routing mechanism such as the EDXL-Distribution Element (DE).
8 Client Registry Exchange DE Message Container Information Needs
The Client Registry Exchange message high-level entity is the top-level element which contains information that uniquely identifies and describes a particular Client Registry Exchange message. The Client Registry Exchange message MUST contain the following elements of information:
Message ID (required) – MUST carry an identifier to uniquely differentiate each Client Registry Exchange message. The identifier must include an ID or number.
System ID (optional) – a Client Registry Exchange message may optionally carry the identifier of the system or device which acts as the data source, or an individual’s login credentials. This may include, for example, mobile hand-held devices used by practitioners in the field.
9 XML Schema and XML Instance documents for Registry (PFIF) Atom and RSS Feeds SHALL use “pfif:” as the namesace prefix.
Atom Distribution Information Requirements follow:
10 Atom “PERSON” information feeds
Each Atom Feed MUST contain the following elements:
Feed element (one and only one per feed)
Entry element (one or more per feed)
Feed Element:
An Atom PERSON feed provides at least the following elements within the feed element:
Id
This element should contain a unique URI associated with this feed. This might be the URL to the website that corresponds to the database or service providing this feed.
title
This element should contain the name of this feed. This should include the title of the database or service providing this feed.
Subtitle
This element should contain a phrase or sentence describing this feed. This would be the place to explain how this feed is produced, for example: "Scraped daily by FooMatic 2.3 from http://example.org/".
updated
This element should contain the date and time in UTC that this feed was last updated, given
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 59
Registry Exchange Information Requirements
in "yyyy-mm-ddThh:mm:ssZ" format.
link
This element should contain a URL from which this feed can be retrieved. This element should have a rel attribute whose value is self.
Entry Element:
An Atom “PERSON” feed provides at least the following elements within each entry element:
pfif:person
This element contains child elements for the fields of the PERSON record, as well as zero or more pfif:note elements. A service wishing to provide a complete export would include all the note records associated with the person here.
id
This element should contain a URI string consisting of the scheme "pfif:" followed by the value of the person_record_id field.
title
This element should contain the value of the first_name field, followed by a space and the value of the last_name field in the person record.
author
This element should contain a name element containing the value of the author_name field and an email element containing the value of the author_email field in the person record.
updated
This element should contain the value of the source_date field in the person record.
content
This element should contain a human-readable HTML formatting of the information in the person record. It is up to the application to decide how to format the content.
source
This element should contain a copy of the title element of this feed. This element may also contain copies of any other child elements of the feed element.
RSS Distribution Information Requirements follow:
11 Client Registry RSS Feeds
Client Registry (PFIF) XML documents can be embedded into RSS 2.0 feeds. (In RSS 2.0 terminology, this section defines an RSS 2.0 module.) The Registry (PFIF) document should be specified using an XML namespace and embedded as an immediate child of the item element.
RSS 2.0 defines two main elements
channel
item
These elements are enclosed in a top-level RSS element.
12 The Client Registry Exchange should support the following RSS feeds:
PERSON feeds in which each item contains a PERSON record
NOTE feeds in which each item contains a NOTE record
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 60
Registry Exchange Information Requirements
Refer Client Registry Requirement #16 and #17 for details on PERSON record element information requirements
13 RSS “PERSON” feed
Channel Element:
An RSS person feed provides at least the following elements within the channel element:
title
This element should contain the name of this feed, which should include the title of the database or service providing this feed.
description
This element should contain a phrase or sentence describing this feed. This is the place to explain how this feed is produced.
lastBuildDate
This element should contain the date and time in UTC that this feed was last updated, given in RFC 822 date format, for example: "Sat, 07 Sep 2002 00:00:01 GMT".
link
This element should contain a URL to the website that corresponds to the database or service providing this feed.
Item Element:
An RSS person feed provides at least the following elements within each item element:
pfif:person
This element contains child elements for the fields of the person record, as well as zero or more pfif:note elements. A service wishing to provide a complete export would include all the note records associated with the person here.
guid
This element should contain the value of the person_record_id field.
title
This element should contain the value of the first_name field, followed by a space and the value of the last_name field.
author
This element should contain the value of the author_email field, followed by a space and the value of the author_name field enclosed in parentheses.
pubDate
This element should contain the date in the source_date field in the person record, converted to RFC 822 date format, for example: "Sat, 07 Sep 2002 00:00:01 GMT". The timezone MUST be GMT and the year MUST have four digits.
description
This element should contain a human-readable HTML formatting of the information in the person record. It is up to the application to decide how to format the description.
source
This element should contain the value of the source_name field.
link
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 61
Registry Exchange Information Requirements
This element should contain the value of the source_url field.
14 RSS NOTE feed
An RSS note feed provides at least the following elements within the channel element:
title
This element should contain the name of this feed. This should include the title of the database or service providing this feed; followed by a more specific title that describes how the notes were selected from the database or service.
description
This element should contain a phrase or sentence describing the feed. This is the place to explain how the feed is produced.
lastBuildDate
This element should contain the date and time in UTC that this feed was last updated, given in RFC 822 date format, for example: "Sat, 07 Sep 2002 00:00:01 GMT".
link
This element should contain a URL to the website that corresponds to the database or service providing this feed. For a note feed about a particular person, this link could point to the web page for that person's record.
An RSS note feed provides at least the following elements within each item element:
pfif:note
This element contains child elements for the fields of the note record.
guid
This element should contain the value of the note_record_id field.
author
This element should contain the value of the author_email field, followed by a space and the value of author_name field enclosed in parentheses.
pubDate
This element should contain the date in the source_date field in the note record, converted to RFC 822 date format, for example: "Sat, 07 Sep 2002 00:00:01 GMT". The timezone MUST be GMT and the year MUST have four digits.
description
This element should contain an HTML formatting of the text field in the note record. It is up to the application to decide how to format the description
Registry (PFIF) Exchange Information Requirements follow:
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 62
Registry Exchange Information Requirements
15 PERSON Record metadata
The Client Registry Exchange MUST contain the following PERSON Record metadata information associated with the client. See the TEC Data Dictionary for definitions of each element.
person_record_id (required)
entry_date
expiry_date
author_name
author_email
author_phone
source_name
source_date (required)
source_url
16 PERSON Information
The Client Registry Exchange MUST contain the following PERSON Record information associated with the client. See the TEC Data Dictionary for definitions of each element.
full_name (required)
first_name
last_name
sex
date_of_birth
age
home_street
home_city
home_neighborhood
home_state
home_postal_code
home_country
photo_url
other
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 63
Registry Exchange Information Requirements
17 NOTE Record Metadata
provides additional information entered over time about a person in the registry, such as to link person records for the same person entered separately in difference or the same registry to assist in searches to locate a person.
note_record_id (required)
person_record_id
linked_person_record_id
entry_date
author_name (required)
author_email
author_phone
source_date (required)
18 NOTE Information
provides information about a person who has been found or reported missing, their location or other pertinent information that might be useful to help in search
found
status (information_sought | is_note_author | believed alive | believed_missing | believed_dead)
email_of_found_person
phone_of_found_person
last_known_location
text (free text) (required)
19 Registry Exchange Message relationships: PERSON
The Registry Exchange message design MUST enforce the following information relationships for each message, as represented in the Element Reference Model (ERM):
Each Registry Exchange record represents only one Person (Client) and related PERSON metadata.
20 Registry Exchange Message relationships: PERSON and NOTE
The Registry Exchange message design MUST enforce the following information relationships for each message, as represented in the Element Reference Model (ERM):
Each Registry Exchange message MUST contain at least one PERSON record OR at least one NOTE record.
Each Registry Exchange message may contain zero or more PERSON records.
Each Registry Exchange message may contain zero or more NOTE records associated with the associated PERSON record to be sent.
876
5.3.4 Conformance Requirements 877
Client Registry Exchange Message Conformance Requirements are shown below: 878
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 64
A Client Registry Exchange Message Constraint Schema or Profile MUST not become a new or 879 additional messaging “standard” (another Client Registry Exchange Message “version”). It is simply 880 a more constrained version of an existing messaging standard. 881
A Client Registry Exchange Message Constraint Schema or Profile message MUST comply with the 882 OASIS Client Registry Exchange Message standard. 883
A Client Registry Exchange Message Constraint Schema or Profile message MUST always validate 884 against the OASIS Client Registry Exchange Message standard Schema. 885
A Client Registry Exchange Message Constraint Schema or Profile message MUST validate within 886 the OASIS Client Registry Exchange Message standard namespace with no changes to root 887 elements. 888
A Client Registry Exchange Message Constraint Schema or Profile message MUST use all required 889 elements (i.e., no deletion of required elements are allowed). 890
A Client Registry Exchange Message Constraint Schema or Profile message MUST not change 891 attributes for required fields. 892
A Client Registry Exchange Message Constraint Schema or Profile / message MUST NOT be a 893 Proprietary Format. 894
A Client Registry Exchange Message Constraint Schema or Profile message MAY further constrain 895 the Client Registry Exchange Message standard.* 896 (* may be thought of as a “constraint Schema” against the standard) 897
A Client Registry Exchange Message Constraint Schema or Profile message MAY add to required 898 element definitions.* 899 (* only to extend or interpret the definition) 900
A Client Registry Exchange Message Constraint Schema or Profile message MAY limit the size of 901 required elements. 902
A Client Registry Exchange Message Constraint Schema or Profile message MAY exclude optional 903 elements. 904
5.4 Registry Exchange Message Specification 905
Though the final OASIS product will reflect improved and more detailed modeling and definition, this 906 section provides a logical graphic and tabular representation of the standard message requirements, 907 information needs and definitions, attributes (such as cardinality) and relationships. 908
This section MUST be considered in whole with the requirements and rest of the document within the 909 OASIS process, and is organized into the following major sections. 910
Registry Exchange Message Distribution 911
Registry Exchange Message “Required Elements” Model 912
Registry Exchange Message Element Reference Model (ERM) 913
Registry Exchange Message Common Elements Model 914
5.4.1 Registry Exchange Message Structure (Normative Unless 915
Otherwise Stated) 916
This section of the document is normative unless otherwise stated. If any differences are found between 917 the models and the data dictionary, then the data dictionary shall always take precedence and the other 918 artifact(s) must be changed to match the data dictionary. 919
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 65
This draft messaging specification and resulting schema provides an overall element reference schema, 920 used either in whole or applying constraint schemas during implementation. A constraint schema is 921 simply a subset of the standard reference schema which conforms to all the requirements and business 922 rules of the reference schema. For example, an implementation of the standard may eliminate selected 923 optional elements, or enhance the definition of a required element. 924
The message structure and data dictionary is defined using successively more detailed or constrained 925 artifacts in the form of diagrams, figures and tables. The purpose of the diagrams is to highlight the 926 structure of the framework and the relationships between the main blocks / entities and their elements 927 (represented as lines on the diagram). Models and data dictionary taxonomies reflect practitioner terms, 928 rules and requirements, and should reflect and agree with Section 5.3 “Statement of Requirements 929 (Normative)”. 930
The logical structure of the message is presented using 3 standard models. With the Data Dictionary this 931 provides an overall definition of the practitioner requirements in the form of message structure (element 932 cardinality), message element definitions and cardinality which must be adhered to. “Cardinality” defines 933 the number of possible occurrences of one element (a person may have many 934 “personalIdentificationTypes” such as drivers license and passport), or how groups of elements link to 935 one another (each patient may have multiple care records). 936
Required Elements Model – The Tracking Message is first represented in a basic model which 937 reflects only the required or conditional elements. This provides a snapshot of the minimum 938 elements required to send or receive a message through entry or defaulting of known information. 939
Element Reference Model (ERM) – The ERM provides a full model which represents a complete 940 message with all required and optional elements. This is the main structure from which 941 individual constraint schemas (individual reports/message types) may be defined and routed 942 utilizing the EDXL-DE or equivalent routing mechanism. 943
Supporting Elements Model - Finally, elements which are used in common / repeatedly in support 944 of various sections of a message are represented in the Supporting Elements model. Here and in 945 the data dictionary, these elements are defined once for re-use where needed, including 946 Location, Contact and ValueList (code list) information. 947
Boxes on the diagram (“entities”) are used to define message structure by grouping related message 948 elements / tags and defining relationships between blocks of information (represented by lines on the 949 diagrams). 950
Textual descriptions of these message models may be found by referring to Section 5.3.3, “Information 951 Requirements”. Requirements #15 to #18 describe Information needs in terms of the data elements 952 required. Requirements #19 and #20 describe relationships of the various data within the message 953 structure (represented by lines between blocks). Finally, Requirements #21 and #22 describe information 954 needs in terms of the supporting data elements required. 955
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 66
Section 6 - Data Dictionary provides definitions of each component group of element and each element 956 within these models. 957
The following key should be referenced in order to read each of these models. 958
Model KEY:
Each block connected by lines denotes a block of information containing one or more elements which belong to / describe that block (e.g. as one or more attributes describe an Entity in an Entity Relationship Diagram (ERD)).
A dashed-line block indicates required elements / capability, but not being defined within the
scope of the diagram or this Registry Exchange standard
The “diamond” end of a line is drawn from a block to the “sub-elements” that belong to or describe that block. The “diamond” end block is above in the hierarchy (the “parent”); thus the connected block is “associated with” or “belongs to” that higher level block.
Lines between blocks (i.e. cardinality / number of occurrences of a group of elements) are read as follows:
One and only one
Zero or one
One or many
Zero or Many
( c ) following an element designates a “Conditional” element (vs. Required or Optional)
On the full Registry Exchange Element Reference Model (ERM), bold element names are either required or Conditional. Non-bold elements are optional NOTE that the diagram in 3.3.1 shows required elements ONLY, and therefore are not bolded.
Underlined elements indicate reference to supporting elements being reused
An asterisk (*) next to an element designates the element may be used multiple times (i.e. element cardinality – multiple occurrences vs. only one)
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 67
5.4.1.1 Registry Exchange Message Required Elements Model 959
The following reflects the basic model showing ONLY the required and conditional elements, providing 960 a snapshot of the minimum elements required for sending or receiving a Registry Exchange message. 961
962
Figure 7 – Client Registry Exchange – Required Elements Model 963
5.4.1.2 Registry Exchange Message Detailed Element Reference Model (ERM) 964
The ERM represents a detailed view of the logical structure of Registry Exchange Message. The purpose 965 of the ERM is to highlight the more detailed structure of the framework and the relationships between the 966 main entities and their elements. With the Data Dictionary this provides an overall definition of the 967 practitioner requirements in the form of message structure (element cardinality), message element 968 definitions and cardinality which must be adhered to. This model shows required elements in bold. 969
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 68
970
Figure 8 – Client Registry Message – Element Reference Model 971
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 69
6 Data Dictionary (Normative) 972
{ 973
NOTE to Steering Committee Reviewers: Please refer to 974
separate TEC Data Dictionary excel spreadsheet for details 975
for each of the message elements. After consensus is 976
reached on the details of the elements in the data dictionary 977
(excel file), the information will be transferred to the 978
individual table forms shown by example in Section 5.2 979
below 980
} 981
The data dictionary is intended to provide detailed definition of each block of information (“entity”) and 982 each element represent in the message models in order to meet all message exchange requirements. 983 Though the data dictionary is typically presented in standard OASIS format using one information table 984 for each element, this data dictionary is presented in the form of table rows for each element with 985 columns providing definition attributes. 986
This table format was also used to map required exchange elements to other relevant efforts for re-use 987 consideration (ARC, FEMA, PFIF, NEMSIS, AHRQ, and NIEM). Due to space, columns providing 988 mapping to other effort elements are not included in this document. However, the full mappings of 989 message exchange elements to these other efforts may be referenced at <<insert evotec public 990 location for complete dictionary file>> The table is organized by entity / block of info as presented in 991 the models, rather than alphabetically. 992
6.1 Data Dictionary Column Definitions 993
Message Entity – A logical block of information used to group elements an allow definitions of 994 relationships. 995
Element – Name of the information element. 996
Type – Type or format of the element. 997
Usage – Specifies whether the element is Required, Optional, or Conditional 998
If no optionality is specified, then the element is “Optional”. 999
If no Cardinality is specified, the element “MUST be used once and only once” 1000
Definition – Definition of the element as required for this messaging standard 1001
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 70
Valid Values/Examples – A list of values that apply to this particular element, or examples which apply in 1002 order to clarify the definition. Where valid values are specified for ValueListURN/Value type pairs, these 1003 values are suggested as defaults, allowing implementations to use their own value list, or insert their own 1004 value by extending the defaults. 1005
Comments – Additional comments or examples to add clarity. 1006
Source – Source of the requirement or usage of the element. 1007
Requirements Supported – Number of the requirement supported by the element (TO BE PROVIDED 1008 IN A SUBSEQUENT VERSION). Key: 1009
G# - “General” requirement number. 1010
F# - “Functional” requirement number. 1011
I# - “Information” requirement number. 1012
Where valid values are specified for ValueListURI/Value type pairs, these values are suggested as 1013 defaults, allowing implementations to use their own value list, or insert their own value by extending the 1014 defaults. 1015
1016
1017
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 71
6.2 Routing Header Elements 1018
Group of elements used for message routing. 1019
Element DistributionType
Type xs:string
Usage REQUIRED
Definition The function of the message . Value must be one of: a. Report - New information regarding an incident or activity. b. Update - Updated information superseding a previous message. c. Cancel - A cancellation or revocation of a previous message. d. Request - A request for resources, information or action. e. Response - A response to a previous request. f. Ack - Acknowledgment of receipt of an earlier message. g. Error - Rejection of an earlier message (for technical reasons).
Valid Values/Examples
Valid Values: Report, Update, Cancel, Request, Response, Ack, Error
Comments 1. Note that where an existing EDXL-DE element meets a stated practitioner requirement, that element will NOT be replicated, duplicated or referred to in the body of a Message. The assumption and rule is that the EDXL-DE or equivalent will be used to route messages, and therefore these requirements are met by the DE. 2. The EDXL-DE, “DistributionType” element meets this requirement. Each of the Valid Values shown above will be treated as an enumeration in the modeling tool.
Source EDXL-DE
Requirements
Supported
Functional Requirement #’s 6,11; Information Requirement #2
1020
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 72
APPENDICES 1021
The following appendices are provided to assist reading of the Specification. Please also refer to the 1022 appendices contained in the EDXL-TEC Project Initiation Document (PID) for additional information. 1023
APPENDIX A - EDXL-TEC Steering Committee Acknowledgements 1024
The following Emergency Professionals invested significant and valuable volunteer time, travel and effort 1025 as members of the TEC Steering Committee. This Steering Committee helped drive development of the 1026 PID and this draft Requirements and Messaging Specification document to facilitate vetting and 1027 consensus across a broad stakeholder community. Each member is gratefully acknowledged. 1028
1029
TEC Project Working Group / Steering Committee Members 1030
Organization Primary Contacts
Title Review/Response Alternate
Contacts
DoD Office of the Assistant Secretary of Defense (OASD) -Homeland Defense and Americas’ Security Affairs
DoD Office of the Assistance Secretary of Defense (OASD) Health Affairs
Christy Music
Scott Henderson
Program Director, Health & Medical Defense Support of Civil Authorities
Program Manager, Document and Information Collection and Management Program
DHS Office of Health Affairs (OHA)
Sally Phillips Mike Zanker
National Guard Bureau
John Foley Contractor, NGB-J35
National Institute of Health (NIH) - National Library of Medicine -Lost Person Finder
Glenn Pearson Project Co-Lead/Senior Developer LPF Communications Engineering Branch
Michael Gill
FEMA - Scott Bowman
- Waddy Gonzalez
- Individual Assistance Division, Systems Development /Integration Deputy Branch Chief
- Mass Care & Emergency
- - Kenneth Graham
- Scott Shoup
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 73
Organization Primary Contacts
Title Review/Response Alternate
Contacts
Assistance Branch Section Chief
Maryland Department of Human Resources Division of Administrative Operations
Pamela Spring Director Office of Emergency Operations - ESF 6 Lead
- - John Donahue
- David Bohannon
Department of Emergency Medicine LSU Health Sciences Center – Shreveport, Emergency Nurses Association (ENA)
Knox Andress Designated Regional Coordinator Louisiana Region 7 Hospital Preparedness
Tennessee Department of Health
Jeff Sexton Preparedness and Response
Captain Robert Newsad
Department of Transportation (DOT)
Drew Dawson Director Office of Emergency Medical Services National Highway Traffic Safety Administration
- - Gam Wijetunge
- Gregory Brown
- Susan McHenry
Department of Health and Human Services Office of Preparedness and Emergency Operations
Joe Lamana Senior Program Analyst Response Operations
- - Linda Cashion
- Charles Knell
- Darryl Britt
Department of Veterans Affairs
Kevin Hanretta Deputy Assistant Secretary for Emergency Management
Michael Feeser
American Red Cross Katherine Galifianakis
Manager, Mass Care and Family Reunification
Dee Yeater
Mary Casey-Lockyer
National Association of State EMS Officials, DHS Practitioner Steering Group (PSG)
Kevin McGinnis
Los Angeles Fire Department
Xenophon "Yo" Gikas
Captain
New Jersey Office of Homeland Security
David Gruber Special Assistant to the Director
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 74
Organization Primary Contacts
Title Review/Response Alternate
Contacts
and Preparedness
Heartland Center for Public Health Preparedness - St. Louis University School of Public Health
Michael W. Thomas Associate Director
State of Texas Department of State Health Services
- David Lakey
- Bruce Clements
- Commissioner
- Director, Community Preparedness Section Department of State Health Services Division for Prevention and Preparedness
Richard Bays
St. Louis City Emergency Management Agency
Gary A. Christmann Commissioner
1031
EDXL-TEC Project Details 1032
Project Name EDXL Tracking of Emergency Clients (EDXL-TEC)
Sponsor/ DHS Lead DHS-S&T-OIC, Denis Gusty
Practitioner Lead Kevin McGinnis (see below)
Project Staff Lead Tim Grapes SE Solutions, Inc. Office: (703) 251-4848 Mobile: (703) 304-4829 [email protected]
Project Work Group / Steering Committee Members
(SEE BELOW)
Stakeholder Community SEE APPENDIX A
Start Date: Research Phase: Q4, 2008
Project Start: January, 2009
Completion Date:
Target Standards Development Organization (SDO) submission Q1, 2010
ACTUAL: May, 2010
1033
1034
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 75
APPENDIX B - Glossary / List of Acronyms 1035
1036
AHRQ Agency for Healthcare Research and Quality 1037
CAP Common Alert Protocol 1038
CBRN Chemical, Biological, Radiological, Nuclear 1039
CDC Centers for Disease Control 1040
DE Distribution Element 1041
DHS Department of Homeland Security 1042
DOB Date of Birth 1043
DOD Department of Defense 1044
ED Emergency Department 1045
EDXL Emergency Data Exchange Language 1046
EIC Emergency Interoperability Consortium 1047
EMS Emergency Medical Services 1048
EM-TC Emergency Management Technical Committee 1049
ER-EHR Emergency Responder Emergency Health Record 1050
ERM Element Reference Model 1051
ESF Emergency Support Function 1052
ETA Estimated Time of Arrival 1053
FMS Federal Medical Stations 1054
HAVE Hospital Availability Exchange 1055
HIPAA Health Insurance Portability and Accountability Act 1056
HITSP Healthcare Information Technology Standards Panel 1057
HL7 Health Level 7 1058
HSPD-21 Homeland Security Presidential Directives 1059
HTTP Hypertext Transfer Protocol 1060
IT Information Technology 1061
MCI Mass Casualty Incident 1062
NASEMSO National Association of State EMS Officials 1063
NEMSIS National EMS Information System 1064
NIST National Institute of Standards 1065
NGO Non-Governmental Organization 1066
NIEM National Information Exchange Model 1067
NIMS National Incident Management System 1068
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 76
OASIS Organization for the Advancement of Structured Information 1069
Standards 1070
OIC Office for Interoperability and Compatibility 1071
ONC Office of the National Coordinator 1072
PFIF People Finder Interchange Format 1073
PII Personally Identifiable Information 1074
PID Project Initiation Document 1075
PSG Practitioner Steering Group 1076
RM Resource Messaging 1077
RSS Really Simple Syndication and Rich Site Summary 1078
SDO Standards Development Organization 1079
SitRep Situation Reporting 1080
SOAP Simple Object Access Protocol 1081
SOP Standard Operating Procedure 1082
SSN Social Security Number 1083
TEP Tracking of Emergency Patients (standard) 1084
TWIRP Texas WebEOC Interoperability Project 1085
SWG Standards Working Group 1086
XML Extensible Markup Language 1087
1088
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 77
APPENDIX C - Definitions 1089
1090 The table provides definitions of just a few key terms for this effort. 1091 1092
TERM DEFINITION
Client A person who is displaced, evacuated, sheltering in place, and/or requiring evacuation support or attention.
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 standard may eliminate selected optional elements, or enhance the definition of a required element.
Cardinality “Cardinality” defines the number of possible occurrences of one element (a person may have many “personalIdentificationTypes” such as drivers license and passport), or how groups of elements link to one another (each client may have multiple encounters during the course of an incident).
Element “Tags” or “labels used as the placeholder for carrying commonly defined data element(s) / pieces of information with a common definition
Entity Logical groupings of message elements or “blocks” of information describing the same “thing” for purposes of defining message structure and the relationships between those blocks of information. In the ERM diagram, boxes are entities; the relationships are represented by lines between the boxes.
EMS incident continuum of care
For the purposes of TEP the EMS incident continuum of care is initiated by the initial contact between a client and a Care Provider (see Care Provider definition) and concludes when a patient is released, admitted to a fixed medical facility, or transferred to the medical examiner/morgue.
Emergency Responders
Agencies and personnel with authoritatively recognized responsibility for responding to emergencies and disasters of any scale. Examples include: fire service, law enforcement, EMS, search and rescue, and public health.
EMS-Care Provider
An individual who holds an active state EMS certification and/or is licensed to practice to medicine, nursing, or another patient care discipline e.g. EMT, physician, nurse.
Encounter or Service Encounter
The first or initial meeting or contact between a given Service Provider and a given Client.
Fixed Medical Facility
A permanent medical facility that is not “intermediate” or “temporary” which offers definitive care for major illness/injury, or offers rehabilitative/custodial care. For purposes of this standard examples include Hospitals, Nursing Homes, and Rehabilitation Centers etc. as fixed “end point” facilities where patients are transported, beyond the realm of emergency care.
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
EDXL Tracking of Emergency Clients (TEC)
Requirements and Draft Messaging Specification 08/31/2012
Final v1.6 August 2012 – Sponsored by DHS Science & Technology Directorate - EDXL Program Page 78
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” as viewed from the NIMS emergency management perspective is 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-TEC may refer to any situation whether an incident, event or other situation or occurrence.
Intermediate Care Facility
A facility that allows for the assessment and treatment of clients until they can either be released (minor illness/injury) or transported to a major/ institutional care facility (major illness/injury). Examples of intermediate care facilities are not limited to but include Triage Areas, Emergency Departments, and Field Hospitals.
Mass Casualty Incident
A situation in which EMS responders are overwhelmed by the number and/or severity of casualties at an incident and require resources beyond those available in their immediate jurisdiction. Typically invokes formal Incident Command Structure to define roles, responsibilities and authority across jurisdictional and professional boundaries.
Patient A person requiring medical oversight or attention, being medically evaluated, or a fatality. For the purposes of TEP, the term patient may be used interchangeable with the term client.
1093 1094 1095
APPENDIX D – Open Issues 1096
A separate issues list (TEC Steering Issues List v 8.1) for the TEC project has been maintained since 1097 development and distribution of the Project Initiation Document (PID). The list maintains all the issues 1098 which have been closed as well as those outstanding (open) and currently “Pending”. Issues remaining 1099 in the “Pending” or “Open” status are passed to the OASIS process for final analysis and disposition. 1100 Approximately 20 of 233 total issues remain in this status. 1101
1102
The list is filtered to display only “Open” and “Pending” issues. Pending issues or comments have been 1103 addressed either by notation in the issues list or within this EDXL-TEP document, but require further 1104 review, "Open" issues or comments have not yet been addressed. 1105
The full issues list can be found on the following site: 1106
http://www.evotecinc.com/TEP/ 1107
1108