EDXL-TEP Requirements & draft Messaging Specification …9 FINAL for submission to the 10 EIC 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 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




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




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




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




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


03/09/2012 Revised Initial Draft TEC Steering Committee 1.0


03/14/2012 Revised Draft resulting from internal project

team review

Project Team 1.1


05/04/2012 Revised Draft resulting from initial Steering

Committee review; and miscellaneous editorial

corrections

Project Team 1.2


05/29/2012 Revised Draft resulting from second Steering

Committee review

TEC Steering Committee, PSG, SWG, Stakeholders and

Vendors

1.3




Author

Date

<mm/dd/yyyy> Reason Reviewers Version


07/20/2012 Revised Draft resulting from second Steering

Committee review

TEC Steering Committee, PSG, SWG, Stakeholders and

Vendors

1.4


08/16/2012 Finalize specification package for submission

to SDO

Final for submission to EIC and OASIS

1.5


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




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

http://www.evotecinc.com/TEC/




http://www.evotecinc.com/TEP/

http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc

http://docs.oasis-open.org/emergency/edxl-have/os/emergency_edxl_have-1.0-spec-os.doc




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





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




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





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




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




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




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




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




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





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

http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc




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




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




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




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




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




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.




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





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.





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




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




"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




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




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




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





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




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.




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





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





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)





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)





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)





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





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





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


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


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





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





– 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





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




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




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




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




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




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




788

Figure 4 – Client Tracking Message – Element Reference Model (ERM) 789

4.4.1.3 Tracking Exchange Message Common Elements Model 790




“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




801

Figure 6 – Client Tracking Exchange Candidate Value List Elements 802

803




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)



Transportation service personnel


- Clients who self-register

- Users who are searching for clients

- News organizations

- Police agencies

- Person-finding websites




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




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


DESCRIPTION




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




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




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





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.





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





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





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





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:





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





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




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




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




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)




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




970

Figure 8 – Client Registry Message – Element Reference Model 971




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




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




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




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






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






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

[email protected]

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

mailto:[email protected]

blocked::mailto:[email protected]




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

http://www.nasemso.org/




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




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




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

http://www.evotecinc.com/TEP/

Date post:	15-Jul-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

EDXL-TEP Requirements & draft Messaging Specification …9 FINAL for submission to the 10 EIC and...

Documents