HSEEP AAR-IP Template - OASIS€¦ · Web viewThere is unpredictable availability of 3G and 4G...

Draft After Action Report / Improvement Plan Tracking of Emergency Patients(AAR/IP) Data Exchange Exercise

Memphis, Tennessee April 29, 2010

Emergency Data Exchange Language (EDXL)Tracking of Emergency Patients (TEP)

Data Exchange ExerciseIn Association With

Tennessee National Disaster Medical System (NDMS)Patient Reception Exercise

Memphis, TennesseeApril 29, 2010

Draft After Action Report/Improvement Plan

For Official Use Only Draft February 6, 20111



ACKNOWLEDGEMENTSThe authors and exercise organizers wish to acknowledge multiple contributors to the success of this exercise.

We gratefully appreciate the Tennessee area Veterans Administration Medical Centers and their affiliated NDMS Federal Coordinating Centers especially James Payne the FCC Coordinator for Memphis for allowing us to bring our objectives into their NDMS reception exercise.

The developers and vendors of the following systems and their developers: HC Standard, DMS First Track, UPP TNCRN, The NDMS JPATS, Intermedix EMSystems all contributed numerous hours in preparation for the exercise and paid to bring their exercise teams to the site of the exercise. These resources were contributed at their own expense without expectation of reimbursement.

Finally, we acknowledge The Department of Homeland Security, Science and Technology Directorate for creating a subject matter expert group and embarking on the EDXL-TEP standard development process, and thank the following organizations and agencies for their participation and contributions to this exercise:

Health and Human Services Department Associate Secretary for Preparedness and Response

Department of Veterans’ Affairs Health Care Services Department of Homeland Security Science and Technology Directorate and their contract

support FEMA Disaster Management Messaging Broker services (now “IPAWS-OPEN”) Maryland Institute for Emergency Medical Services Systems (MIEMSS) Tennessee Department of Health Tennessee Emergency Management Agency Tennessee Air National Guard




ADMINISTRATIVE HANDLING INSTRUCTIONS1. The title of this document is Emergency Data Exchange Language (EDXL) Tracking of

Emergency Patients (TEP) Data Exchange Exercise After Action Report (hereinafter referred to as EDXL-TEPEDXL-TEP DEX) After Action Report/Improvement Plan (AAR/IP).

2. The information in this document, while not confidential, is sensitive in nature. This document should be safeguarded, handled, transmitted, and stored in accordance with appropriate security directives. Reproduction of this document, in whole or in part, without prior approval from the Department of Homeland Security, Science and Technology Directorate is prohibited.

3. The information contained in this AAR is designated FOR OFFICIAL USE ONLY,1 (FOUO) which is a handling instruction, as opposed to a true classification marking. FOUO is used for documents or products that contain material that is exempt from release under the Freedom of Information Act and should be handled as sensitive information not to be disclosed.

4. At a minimum, the attached materials will be disseminated only on a need-to-know basis, and, when not being used, will be stored in a locked container or area offering sufficient protection against theft, compromise, inadvertent access, and unauthorized disclosure.

5. For more information, please consult the following Points of Contact (POCs):

Exercise DirectorDenis GustyBranch ChiefHomeland Security Enterprise and First Responder GroupScience and TechnologyDepartment of Homeland [email protected]

Exercise Support Team Project ManagerTimothy GrapesEvolution Technologies Inc. 2325 Dulles Corner Blvd, Suite 500 Herndon, Va. [email protected]

1 Department of Defense (DoD) Directive 5400.7-R, “Department of Defense Freedom of Information Act Program,” Washington, D.C., September 4, 1998.

Administrative Handling For Official Use Only Draft October 1, 20105

mailto:[email protected]




Contents

ADMINISTRATIVE HANDLING INSTRUCTIONS 5

CONTENTS 6

EXECUTIVE SUMMARY 7

SECTION 1: EXERCISE OVERVIEW 13

SECTION 2: EXERCISE DESIGN SUMMARY17

SECTION 3: ANALYSIS OF CRITICAL TASK PERFORMANCE 18

SECTION 4: CONCLUSION 30

APPENDIX A: IMPROVEMENT PLAN 31

APPENDIX B: EDXL-TEP MESSAGING SPECIFICATIONS 41

Contents For Official Use Only Draft October 1, 2010 6



Emergency Data Exchange Language (EDXL)Tracking of Emergency Patients (TEP)

Data Exchange ExerciseMemphis, Tennessee

April 29, 2010

EXECUTIVE SUMMARYHomeland security preparedness involves a cycle of outreach, planning, capability development, training, exercise, evaluation, and improvement. Successful exercises lead to an ongoing program of process improvement with the overall objectives being more fully prepared to respond to actual events. This report is intended to assist agencies striving for preparedness excellence by:

Identifying strengths to maintain and serve as a foundation for future growth Identifying potential areas for further improvement Recommending exercise follow-up actions

This report follows the guidelines set forth by the U.S. Department of Homeland Security’s (DHS) Office for Domestic Preparedness (ODP) Homeland Security Exercise Evaluation Program (HSEEP). The ODP has published four reference manuals to provide guidance for designing, developing, conducting, evaluating, and reporting results of exercises under the HSEEP. These can be found at http://www.ojp.usdoj.gov/odp/docs/hseep.htm.

The suggested actions in this report should be viewed as recommendations only. In some cases, agencies may determine that the benefits of implementation are sufficient to outweigh the costs. In other cases, agencies may identify alternative solutions that are more effective or efficient. Each agency should review the recommendations to determine the most appropriate actions and the resources needed (i.e., time, staff, and funds), and develop a Corrective Action Plan for implementation. Improvement actions should be established and completed both by the individual agency and, where feasible, in conjunction with the DHS Science and Technology Directorate.

Exercise Design Summary: The National Disaster Medical System (NDMS) Federal Coordinating Centers (FCCs) conducted an exercise using actual air and land transport, and volunteer patients driven by objectives of the FCC, federal, State and Local Agencies and NDMS Partner Hospitals. The exercise scenario involved a hurricane making landfall in Maryland and resulting in 1,000 fatalities and 5,000 people with injuries requiring evacuation to distant healthcare facilities. The exercise involved an actual C-130 transport “landing” in a triage area where patients were cared for and transported to NDMS contracted hospitals in Nashville and Memphis Tennessee (the patients were sent virtually to Memphis by loading them onto the C-130 and then unloading them without actually flying them from Maryland to Memphis.)

Executive Summary For Official Use Only Draft October 1, 20107

http://www.ojp.usdoj.gov/odp/docs/hseep.htm



This movement of patients through several geographic locations and agencies responsible for their care and transportation afforded an excellent opportunity to exercise the operation of the Emergency Data Exchange Language Tracking of Emergency Patients (EDXL-TEPEDXL-TEP) standard. The care of the patients was to be transferred from Maryland to the NDMS through the Memphis Federal Coordination Center and local EMS agencies to Memphis area hospitals with the Tennessee Department of Health acting as the disposition state coordination agency. Each of these organizations has a patient tracking system, which prior to the exercise did not include the capability to share patient tracking data. To enable the required cross-platform and agency patient information-sharing capability, a common standards-based interface (the draft EDXL-TEP standard) was incorporated into each system and the FEMA Disaster Management Open Network for Emergency Networks (DM-OPEN**) was used as a central messaging broker. This provided the ability for each agency’s system to maintain visibility into all patient status and movement, and provide improved situational awareness. EDXL-TEP The systems being integrated in this exercise are as follows.**Note that this system is now referred to as the “IPAWS-OPEN” system.

Patient Tracking Systems UtilizedOrganization System Utilized

Maryland EMSwww.miemss.org

HC Standard by Global Emergency Resourceswww.ger911.com

TN Health Departmentwww.tennessee.gov/health

TNCRN – Upp Technologieswww.upp.com

NDMS DMATndms.dhhs.gov

Joint Patient Assessment and Tracking System (JPATS)

Shelby County HDwww.shelbycountytn.gov

First Track by DM Solutionswww.dmssolutions.com

Note: It is important to note that although EMSystems was involved in the planning for the exercise their EMTrac was not involved in the exchange of data as

their system was not used by the responders for patient tracking.

The objective of the EDXL-TEPEDXL-TEP portion of the exercise was to evaluate and document the use of the standard in an actual patient movement environment and to investigate preparation required to implement the standard.

EDXL-TEP Exercise Participating Organizations:

Department of Homeland Security, Science and Technology Directorate Department of Health and Human Services, Assistant Secretary for Preparedness and

Response Department of Veterans’ Affairs Health Care Services Evolution Technologies, Inc. Disaster Management Solutions UPP Technologies EMSystems




FEMA Disaster Management Messaging Broker services (DM-OPEN) (now “IPAWS-OPEN”)

Global Emergency Resources Maryland Institute for Emergency Medical Services Systems (MIEMSS) Tennessee, Shelby County - Emergency Medical Services, Emergency Resources

Coordinator, Health Department, Hospitals Tennessee Department of Health Tennessee Emergency Management Agency

Overarching Objectives:Demonstrate notional proof of concept and evaluate patient movement and tracking capabilities based upon application of the EDXL-TEP draft standard. Patient flow: Patient Reception Area (PRA), or point of origin, to the Memphis, TN triage area, and then to multiple NDMS hospitals utilizing the Emergency Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Draft Specification, and EDXL-Distribution Element (DE).

1. Assess the ability of the data exchange architecture to be established in a timely fashion and determine methods to facilitate the process.

2. Successfully exchange information on 160 patients using the originating system and information shared between intermediate systems. Track patients to the final hospital disposition and provide visibility through the systems for location and triage status of patients during their movement.

3. Successfully coordinate with and exchange patient tracking information utilizing systems and processes across Federal agencies (HHS and DHS), states (MD and TN), and between state and local (TN state and TN local applications)

4. Identify obstacles and best practices for the implementation of an open data exchange using the EDXL-TEPEDXL-TEP standard.

5. Identify any specific changes that should be incorporated prior to Steering Committee acceptance and submission of the draft standard to OASIS (the standards development organization process).

6. Assess the ability of current communication infrastructure to support the efficient exchange of data.

7. Identify strengths, weaknesses, opportunities, and threats in regard to the tested data exchange process.




Summary of Observations and Findings:The following section summarizes the principal observations, findings, and recommendations for the exercise.

Major Strengths

• A total of 5612 transactions were processed with over 1000 data messages exchanged successfully among the 4 divergent proprietary computer applications.

• No noted slow down in the movement of patients or patient care was observed from the integration of the four systems. Multiple systems / vendors which had never before shared electronic data, quickly and easily sharing patient tracking data through each step of the patient transport and emergency care continuum. All systems seamlessly updated with the latest status and location of each patient at any point in time. All patient information was shared with appropriate organizations prior to arrival improving the organization’s ability to prepare for inbound patients. The time required to exchange patient information was greatly reduced over historic methods through fax and e-mail.

• Maryland officials successfully loaded information on 158 patients into their patient tracking system, HC Standard, and viewed patient information changes throughout the exercise.

• The application used by the NDMS (JPATS) successfully received designated data points into their system and posted that data to the other systems through the message broker.

• Memphis officials were able to view patient information lists in their system, (DMS First Track), prior to arrival of patients.

• Memphis/Shelby officials were able to re-triage patients and coordinate their movement to healthcare facilities based upon the patients needs and hospital availability.

• A complete computer printed hard-copy patient manifest was presented to flight personnel for patients to be transported prior to loading.

• Tennessee Department of Health (TDH) officials were able to view patient location and triage status in their system, (Tennessee Counter Measure Response System), before patients arrived greatly improving their situational awareness. This allowed TDH to ensure that resources were being utilized appropriately and patients were appropriately distributed and treated.

• Four normally competitive software companies appreciated the significance of the effort and operated in a collaborative environment to achieve the goal of seamless integration.

• Cellular data transmission used for data-sharing proved adequate• EDXL-TEP improvements were identified and incorporated into the draft standard prior

to submission to OASIS.

Observations and Findings

Each of the computer application developers recognized specific modifications required to their systems that would improve the operation of each individual application and with the ability to operate in an integrated environment.

The design of the exercise allowed “Paper patients” to be entered at Memphis out of sequence by making them appear to be at Memphis before they were notionally loaded on the plane in Maryland.




Throughout the exercise, a total of 66 volunteer patients were processed and tracked plus 92 additional triage tags that were prepared but for which no volunteers arrived totaling 158 “tracked patients”. 5612 total transitions were processed during the exercise time-frame.

Though procedural issues caused problems (vendors “tracking patients” out of sequence of the actual exercise script), no technical difficulties were encountered with the DM-OPEN (now IPAWS-OPEN) message broker, NeXt360, or the vendor systems including hand-held scanning devices. All perceived technical issues with message sharing were determined and validated to be procedural.

Primary Areas for Improvement and Follow-on Activities:Several opportunities for improvement as well as planned next steps were noted in relation to achievement of the exercise objectives. A full discussion of recommendations is found in the main body of this report and all critical observations and recommendations are collected in the Improvement Plan Matrix in Appendix A. Summary of needed improvements:

Desired and/or Planned Next Steps• Complete and Publish the EDXL-TEP standard by OASIS• Development of Phase II of the TEP standard, expanding this concept to address the

general population (tracking of evacuees and displaced).

Primary Areas for Improvement and follow-onThe following items are recommended for planning and follow-on activities, and require request and prioritization with appropriate organizations and resources.

• Development of detailed TEP implementation guides:• Use Case Templates• Framework for Trading Partner Agreements addressing point to point and

broadcast interchanges.• Enhance marketing and communication about materials, technical libraries and

support that is available to assist and facilitate implementation of standards-based exchanges with partners.

• Draft architecture solutions to support transport of data• Clearly define business rules• Marketing strategy which includes additional exercises, involvement of the press, broad

awareness campaign.• An infrastructure to support the interoperability of divergent data systems should be fully

established, published, and open to all vendors.• During data-exchange planning and implementation, coordinate with regional partners as

well as DHS-S&T and FEMA’s OPEN technical support to determine specific process, procedures and mechanisms agreed upon across your exchange partners to quickly implement patient tracking with “new” partners quickly and easily (see Objective 1 – recommendation 1 below)

• During implementation planning, testing and actual production operation, utilize standard




information-sharing capabilities during day to day incidents so that when a large scale incident occurs, ongoing and escalated tracking becomes seamless.

• Complete coordination with HL7 and OASIS which was originally initiated but not followed through. This should include both Standards Development Organizations and the 3 primary federal entities (DHS, HHS, and DOD).

• Once the EDXL-TEPEDXL-TEP is finalized, there should be multiple exercises to streamline and perfect a given implementation prior to full release for production.

• Develop a specific method that ensures uniqueness of patient/person, date and time, and a method to control sequence of times and locations

• During the exercise, “Paper patients” were processed by Memphis personnel during a lull in the play to expedite flow. This was done before data were transmitted from Maryland and the JPATS applications making it appear that the patients arrived at the Patient Reception Center prior to being transferred in the aircraft.

• Though this cannot occur during an actual chain of events, for future exercises, the plan and sequence of events must be better organized and managed much more rigorously, with a single coordinator / gatekeeper authorizing every step and transaction prior to systems action or activity.

• Confusion between definition of “Location” and “Destination” in the draft TEP profile of the standard used in the exercise was identified. This must be better defined in subsequent exercises and must be clarified in the standards document (for the exercise, actual “location” XML components were not used, and replaced with simple text).

• Communication systems (cellular data transmissions) appeared adequate for this exercise, but data transmission options require more consideration for use in actual emergencies.

• There is unpredictable availability of 3G and 4G hardware and service capability across the US

• DOD facilities across the US that have been designated as “Reception Centers” should have communications capacity to support bandwidth requirements for a large-scale patient movement.

• Investigate methods of minimizing obstacles involved in the planning and participation in exercises such as this:

• Encourage vendors to actively participate in planning calls, ask questions, provide updates and status, and to talk and coordinate with each other while protecting their proprietary information and competitive positions.

• Investigate technical obstacles that prevented one vendor to connect directly with the main messaging broker (OPEN). Although java was required and the vendor is a .net shop, all necessary components were provided in order to connect.

• During standards-based exchange implementation planning and incident planning, incorporate coordination with all known or anticipated partners and vendors planning to share patient data to agree up front on the technical mechanism / strategy for data-sharing / brokering of standard messages (e.g. utilize DM OPEN 2.0, another message broker capability, or some other option).

• Require standards participation by all federal grantees as vendor plans for application of standards-based information sharing can run counter to competitive business plans.




SECTION 1: EXERCISE OVERVIEWExercise Details

Exercise Name: Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP)/ Data Exchange Exercise

Type of Exercise:Full Scale Exercise associated with a Tennessee NDMS Reception Exercise

Exercise Start Date:April 29, 2010

Exercise End Date:April 29, 2010

Duration:6 hours

Location:Memphis, Tennessee

Exercise Site(s):Tennessee Air National Guard 164th Airlift Wing

Sponsors:United States Department of Homeland Security, Science and Technology Directorate

Contact: Denis GustyBranch ChiefHomeland Security Enterprise and First Responder GroupScience and TechnologyDepartment of Homeland [email protected]

United States Department of Health and Human Services, Assistant Secretary Preparedness and Response

Contacts: Joseph LamanaSenior Program Analyst Response Operations HHS/ASPR/[email protected]

Section 4: Conclusion For Official Use Only Draft January 18, 201113





Program:

DHS, Science and Technology Directorate

Mission:To exercise and demonstrate the ability to track patients from the scene of a disaster to distant hospitals through several proprietary computer applications through the use of a standard data exchange language.

CapabilitiesThe following capabilities and critical tasks were investigated during this exercise in light of exercise objectives and scenario elements:

Develop procedures for the exchange of voice and data with federal, regional, state, local, and voluntary agencies

Develop interoperable telecommunication and information technology systems across governmental departments and agencies at various levels.

Develop and/or maintain protocols and procedures for EMS dispatch, assessment, triage, treatment, transport, logistical support, medical command and coordination, safety, communications, and tracking of patients during day-to-day operations as well as catastrophic incidents.

Initiate a patient tracking systems Coordinate and integrate triage/re-triage, transport, and provide pre-hospital

treatment operations with various agencies. Ensure emergency system patient transport and tracking systems are interoperable

with national and Department of Defense systems.The Exercise Evaluation Guides (EEGs) for these capabilities (adapted for exercise objectives) were used during the exercise to measure and validate performance of these capabilities and their associated critical tasks (by activity).

Scenario TypeThe overall exercise focused on the reception of patients to the Memphis area from a distant area affected by a hurricane through the NDMS. The EDXL-TEP- TEP sub-exercise focused on the patient tracking operation utilizing multiple disparate vendor systems with a mass-movement of patients.

Exercise Planning Team LeadershipTimothy Grapes

Evolution Technologies Inc. 2325 Dulles Corner Blvd, Suite 500 Herndon, Va. [email protected]





Paul Petersen, Pharm.D.,BCPS

Tennessee Department of HealthEmergency Preparedness425 5th Ave North,1st Floor, Cordell Hull BldgNashville TN 37243

Jeff SextonTennessee Department of Health, Office of Technology Services425 5th Ave NorthCordell Hull 6th

Nashville, TN [email protected]

Robert Newsad, PHSTennessee Department of HealthEmergency Preparedness425 5th Ave North,1st Floor, Cordell Hull BldgNashville TN 37243

John DonohueChief, Field OperationsMaryland Institute for Emergency Medical Services Systems653 West Pratt StreetBaltimore, Maryland [email protected]

Stan KuziaCEO Global Emergency Resources

Jay O’donnell Disaster Management Solutions

James Payne VA Health Care NDMS Federal Coordinating Center

Jeff Atkins, CTOUPP Technologies

Bill Heddgcock, CTO






Intermedix EMSystems

Participating Organizations Department of Homeland Security, Science and Technology Directorate Department of Health and Human Services, Assistant Secretary for Preparedness and

Response, National Disaster Medical System Department of Veterans’ Affairs Health Care Services FEMA Disaster Management Messaging Broker services Maryland Institute for Emergency Medical Services Systems (MIEMSS) Shelby County Health Department Tennessee Department of Health Tennessee Emergency Management Agency Tennessee Air National Guard

Supporting Organizations Disaster Management Solutions EMSystems Evolution Technologies, Inc Global Emergency Resources. UPP Technologies

Number of Participants Players: 18 Controller/Evaluators: 2

Simulators: A total of 66 volunteer patients were processed and tracked plus 92 additional triage tags that were prepared but for which no volunteers arrived totaling 158 “tracked patients”.




SECTION 2: EXERCISE DESIGN SUMMARYExercise Purpose and DesignThe Department of Homeland Security (DHS), Office of Science and Technology has been collaborating with the National Association of State Emergency Medical Services Officials (NASEMSO) to develop a standard to enable the exchange of data between disparate patient tracking applications. The project steering committee recently published a draft data and messaging standard for comment. The final standard is to be submitted to the Organization for the Advancement of Structured Information Standards (OASIS) for final acceptance as a formal data standard.

While nearing the completion of the comment period the opportunity presented to test a limited portion of the data and messaging standard during the actual movement of patients associated with a Tennessee NDMS Patient Reception Exercise. During the exercise, 5 patient tracking applications were utilized. The participants hoped to utilize the EDXL-TEP- TEP standard to exchange data between all applications and allow all authorized users to determine the location of any patient during the movement from the distant disaster in Maryland to Tennessee.

The design of this exercised focused on the technical aspects of data exchange. The infrastructure (wires) to allow the systems to communicate had to be engineered. Not all systems contained all the draft standard data points so a subset of the standard was chosen for data exchange. The data exchange was designed to be seamless and not interfere with patient care. Patient cards and Maryland triage tags were coordinated and preset so the activity of initial triage was simulated. The full technical design for the messaging can be found in Appendix B.

Exercise Objectives, Capabilities, and ActivitiesCapabilities-based planning allows for exercise planning teams to develop exercise objectives and observe exercise outcomes through a framework of specific action items that were derived from the Target Capabilities List (TCL). This exercise focuses on the technical aspects of exchanging data between the divergent applications. Hence the objectives focus on those engineering details that allow the critical tasks to be preformed.

Objective 1: Assess the ability of the data exchange architecture to be established in a timely fashion and determine methods to facilitate the process. Evaluate and compare point to point interchanges, published interchanges and

subscription (broadcast) interchanges

Objective 2: Successfully exchange information on 160 patients using the originating system and information shared between intermediate systems. Track patients to the final hospital disposition and provide visibility through the systems for location and triage status of patients during their movement.




Measure and document data quality exchanged during the exercise.

Objective 3. Successfully coordinate with and exchange patient tracking information utilizing systems and processes across Federal agencies (HHS and DHS), states (MD and TN), and between state and local (TN state and TN local applications)

Objective 4: Identify obstacles and best practices for the implementation of an open data exchange using the EDXL-TEP- TEP standard Document the complexity of the EDXL-TEPEDXL-TEP draft standard, implementation

of the standard, and exchange quality with use of the standard. Gather data and information to support the development of detailed implementation

guides to be published for use nationally

Objective 5: Identify any specific changes that should be incorporated prior to Steering Committee acceptance and submission of the draft TEP standard to OASIS (the standards development organization process).EDXL-TEP

Objective 6: Assess the ability of the current communication infrastructure to support the efficient exchange of data

Objective 7: Identify strengths, weaknesses, opportunities, and threats in regard to the tested data exchange process Document overlaps or opportunities and create step by step improvement plans. Identify situational awareness improvement opportunities

Scenario SummaryA category 5 hurricane is approaching the mid-Atlantic coast with the mouth of the Chesapeake Bay in the center the cone of probable landfall. The Bay has many tributaries and major metropolitan areas in low lying areas including Baltimore and Annapolis. Additionally a major ocean resort, Ocean City, lies just north of the mouth of the Bay and becomes the third most populous area of the state during the summer season.

Maryland and the Delmarva Peninsula partners have extensive evacuations plans including the evacuation of flood vulnerable hospitals. These plans have been activated 72 hours prior to expected landfall. Unfortunately, hospitals in Baltimore, Annapolis and others on the Western shore of the bay that normally accept patients from the Eastern shore must also evacuate due to 160 mile winds and a predicted 20 foot storm surge. All facilities in the Maryland, Pennsylvania and the national capital region are occupied beyond capacity. The Governor of Maryland declared a State of Emergency and requested federal assistance to care for the displaced citizens of Maryland.




In response to Maryland’s request for federal assistance, the Secretary of the Department of Health and Human Services and the Assistance Secretary for Preparedness and Response activated the NDMS to assist in the evacuation. A Disaster Medical Assistance Team was deployed to the Baltimore Washington International - Thurgood Marshall Airport to begin to receive evacuated patients and organize them for air transport to other areas of the country. As other costal areas and the northeast are still vulnerable to the effects of the storm, inland areas of the south were selected as the most secure and prepared to accept patients. Federal Coordinating Centers in FEMA Region IV are activated and the VA cooperates with local partners to establish Patient Reception Areas at the Nashville and Memphis airports.

Maryland officials want to be sure that patients being evacuated can be located and tracked successfully to the new facilities and returned to their homes and reunified with their families. Data sharing portals are opened between Maryland’s GER HC Standard and the JPATS, DMS First Track, UPP and EMSystems in Memphis to track the patients.




SECTION 3: ANALYSIS OF CRITICAL TASK PERFORMANCE

This section of the report reviews the performance response to the stated objectives and describes the demonstrated capabilities, activities, and tasks. In this section, observations are organized by objective and associated activities. Analysis was based on demonstrated response activities, participant feedback, completed Exercise Evaluation Guides, and the After Action Briefing Conference.

A summary of the recommendations and their corresponding objectives can be found in “Appendix A: Improvement Plan Matrix.”

Objective 1: Assess the ability of the data exchange architecture to be established in a timely fashion and determine methods to facilitate the process.

Summary of Observed Capabilities: Two of the members of the EDXL-TEP- TEP Standard Steering committee felt strongly that the draft standard needed to be tested in an operational exercise. As both members had access to off the shelf patient tracking applications they convinced their contractors to participate in the NDMS exercise.

Planning for the exercise began in mid February. At that time, only a draft data standard existed. There was no capability or method to exchange the standard data between systems. All participants agreed that Disaster Management (DM) framework - Open Platform for Emergency Networks (OPEN) (now “IPAWS-OPEN”) (http://www.fema.gov/about/programs/disastermanagement/index.shtm) from FEMA was the best available platform to facilitate the data exchange. Through a long series of conference calls and numerous undocumented hours of development with each of the patient tracking vendors the data schema was finalized and table top testing of data exchange was complete.

One application did not have the ability to connect directly with the main messaging broker (OPEN). Although java was required and the vendor is a “Dot Net” shop, all necessary components were provided in order to connect. Evolution Technologies provided connection to their NeXt360 product to act as a secondary message broker only for that application. To RECEIVE messages from other vendors through OPEN, NeXt360 first received and posted the messages, so that the application could retrieve the post into their system. Messages SENT by application were actually posted to a site where NeXt360 retrieved them – NeXt 360 then sent these messages to OPEN which subsequently were received by the other vendor systems.

At the scene of the exercise it took vendors only about 20-30 minutes to assemble their electronics and establish connections to DM-OPEN. This was done before the start of the


http://www.fema.gov/about/programs/disastermanagement/index.shtm



exercise and test messages were sent to confirm operation before patients were being tracked.

Consequences:

Although the connection to DM-OPEN was made, had this been a real incident such a connection would be next to impossible to complete in the short time required. Response partners would revert to paper, pencil and less accurate means to attempt to track patients. Without a message exchange broker the data will have to be manually exported, emailed to the recipient application and manually imported by the recipient application manager.

Analysis:

The EDXL-TEP- TEP is simply a data standard. Without a message exchange broker data will have to be manually exported, emailed to the recipient application and manually imported by the recipient application manager. This would be required for each of the applications involved in the patient exchange and repeated each time data changed.

DM-OPEN is a non-proprietary operational interoperability backbone that provides a set of non-proprietary "level playing field" web services designed to enable disparate third-party applications, systems, networks and devices to share information using open interoperability standards. As federal infrastructure, DM-OPEN is designed to support the delivery of real-time data and situational awareness to public emergency responders in the field, at operation centers and across all levels of response management. DM-OPEN also serves as a test bed to facilitate the development of open, non- proprietary consensus standards that support interoperable information sharing for the emergency responder community.

In order for the individual applications to exchange data on a “no-notice” basis the process by which they are to pass that information must be pre-established. The applications must be engineered to turn that exchange on and off on an as needed basis.

Recommendations and Improvements

Recommendation 1: Once the EDXL-TEP is finalized DHS S&T should publish a data exchange process utilizing DM-OPEN or other messaging broker. DHS should distribute the participation procedures and business rules to all vendors and managers of patient tracking applications both commercial and government owned/managed. Any federal funding, regardless of funding agency, to support patient tracking activities should be contingent on participation with these procedures and compliance with the EDXL-TEP Standards.

Recommendation 2:DHS S&T, HHS and the OPEN technical support should determine processes, procedures and mechanisms to quickly implement patient tracking with “new” partners “on the fly”.




Recommendation 3:

Commercial vendors and managers of government-owned applications should prepare for the release of the EDXL-TEP and work with the users of the system to allow the seamless implementation of the standard by updating their data elements, preparing exchange messages, and developing a mechanism to quickly turn the data exchange on and off on demand.

Recommendation 4:

The messaging broker needs to have monitoring system to confirm that messages are sent and received from the sending and receiving applications.

Objective 2: Successfully exchange information on 160 patients using the originating system and information shared between intermediate systems. Track patients to the final hospital disposition and provide visibility through the systems for location and triage status of patients during their movement.

Summary of Observed Capability: 5612 messages were exchanged through DM-OPEN successfully exchanging data between the participating systems. The application exchanging data through NeXt360 was not receiving data initially. Coding errors were recognized and repaired which allowed the exchange of data. Because a beta version of NeXt360 was utilized on small development hardware, message caching must be cleared frequently. A large number of messages were serviced the day before the exercise, requiring clearing of the cache to speed processing. Afterwards all messages processed quickly and smoothly. Maryland sent data to JPATS as the patients were entered into HC Standard. JPATS was then used to gauge the exchange in a timed fashion in an attempt to simulate real time. Acceleration of the exercise caused the data exchange to be delayed compared to the physical exercise conduct. JPATS managers accelerated and batched data which caught up with the accelerated flow of the exercise. Although standard security measures were employed (ie encryption, pass word protection etc.) the issue of security of the data was not addressed during this exercise nor was compliance with the HIPAA regulations an who should have access to the protected health information.

Consequence:

Data were successfully exchanged allowing all users to view the status of patients in their own applications. Operational reports, such as a flight manifest were produced as requested. Delays in data reception were experienced; however further investigation demonstrated that messages expected but not yet received had not yet been sent by the




JPATS system at that point in the exercise. Not ensuring strict security measures as per HIPAA and other regulations may result in the lack of adoption of the standard or the breach of these regulations

Analysis:

The concept of data exchange was proven as possible. Delays and difficulties experienced were due to configuration and as a result of attempting to simulate flow of data to meet a real life experience. The data standard was proven to be successful as once data were received in each application it could be interpreted and displayed as data from the application itself. As discussed in relation to the previous objective, the architecture must be pre-established to allow seamless data exchange. Although PHI and compliance with HIPAA regulations is somewhat relaxed during an emergency, every effort should be made to ensure there are efforts to continue to protect the information wherever possible.


Recommendation 1:

Avoid the use of multiple message brokers as it increases the chance of configuration and coding errors. All applications should exchange data directly with a central message broker such as DM-OPEN. Exchange partners should agree upon a common method of data exchange and message brokering to avoid complexities introduced by multiple and different mechanisms performing the same function.

Recommendation 2:

Once the EDXL-TEP standard is finalized repeat the exercise in a more controlled fashion to ensure data exchange is synchronized with the conduct of the exercise play.

Recommendation 3. In future exercises, investigate the compliance with HIPAA regulations by identifying the individuals that should have access to PHI determining if the standard would have impact on those requirements.

Objective 3: Identify obstacles and best practices for the implementation of an open data exchange using the EDXL-TEP standard.

Summary of Observed Capability:

Except for those issues previously identified, there were no obstacles to the exchange of data observed during the exercise. “Paper patients” were processed by Memphis personnel during a lull in the play to expedite flow. This was done before data were transmitted from Maryland and the JPATS applications making it appear that the patients arrived at the Patient Reception Center prior to being transferred in the aircraft.




Consequence:

An actual incident would have precluded those data from being out of sync. However, the delay caused by the scenario and exercise play and incorrect exercise procedure step above resulted in confusion in the analysis of results during the exercise.

Analysis:

This exercise was conducted by the interested parties. Although there were numerous hours spent on the technical details of the data standards and the means to exchange the messages, there was not much preparation for the oversight and conduct of the exercise. An experienced team of exercise planners and controllers should be contracted to ensure future exercises would flow in a more appropriate fashion.


Recommendation 1:

In subsequent exercises associated with the data standards, employ an experienced exercise team that has no vested interest in the success of the data standard to plan and conduct the exercise in full accordance with the Homeland Security Exercise and Evaluation Program (HSEEP). The team could also control the flow of activities according to a Master Scenario Events List (MSEL).

Objective 4

Identify any specific changes that should be incorporated prior to Steering Committee acceptance and submission of the draft TEP standard to OASIS (the standards development organization process).EDXL-TEP


The data elements chosen were adequate to determine the status of the patients. The triage status appeared to be changed in the transfer process, but it was later identified as being caused by erroneous entry by a touch-screen due to icons being placed closely on that application / device. Because the exercise implemented a draft version of the TEP standard prior to the SDO publication process, there was no validation during this exercise to ensure messages conformed with the standard prior to each exchange*. Most date/time stamps were established by the applications. The initial identifying triage tag number was used as the unique identifier for each patient. Receiving responders were unfamiliar with the triage tag and either tried to replace it or did make notations as intended. The full standard was not utilized. The definitions of “Location” and “Destination” were confusing due to simplified application of the TEP standard for this exercise.




*Note: The OPEN platform currently validates current EDXL standards and its development life-cycle plans to put validation in place for each EDXL standard published by the standards development organization.

Consequence:

Changes in triage status can cause serious issues in the preparation for the receipt of patients. Although upon reassessment the status could be updated easily. There was no consequence to the lack of a pre-acceptance validation process, but observers were concerned that the lack of such a process could seriously corrupt a database as the number of data elements is expanded. Date and time stamps being produced by the applications should not be an issue as long as the hardware is updated to the current dates and times. Hand entry of those data may be more problematic as it introduces the possibility of more human error. Requirements for a data standard must be built into the system to establish a unique identifier because removal of an original triage tag would disconnect that identifier from that patient and resulting in the inability to continue to track the patient. Mis-entry of information on the tag itself may result in incorrect data in the exchange process. The confusion over location and destination can result in assuming a patient is already at the final destination when they are in-fact still in transit.

Analysis:

The issue of mis-entry of data can be resolved by ensuring that users are very familiar and practiced with the input devices and that redundant checks are done to ensure that such errors can be avoided wherever possible.

A means to accept that an application meets the standard prior to an attempt to exchange will help in the prevention of corrupt data. This may be accomplished through the use of the DM-OPEN platform for published standards, and/or through the use of a conformant message broker product, or through vendor software validation where the vendor has successfully completed the NIMS STEP EDXL Test and Evaluation process. Automated message validation processes will also assist in producing valid information. Use of the full data standard may help to clarify some of the confusion over location and destination, since the exercise did not utilize the same location and destination structures planned for the final standard.

The date/time stamp concerns would probably be eliminated had the exercise run in real time and the “Paper” patients not been read early. In the stress of an actual event, manual entry of data may introduce additional errors.

Use of an initial triage tag seems to be the most desired method to establish a unique identifier for each patient. If that identifier is changed during the process, the initial users of the exchange process can no longer have visibility for that particular patient. This may require additional standardization of triage tags using a single unique identifier to avoid the education process with subsequent users. The CDC is currently investigating updating triage standards and may provide some guidance on standardization when the project is complete.





Recommendation 1:

Each application developer and manager should review the results of the exercise and determine where they can improve their applications to minimize erroneous data entry.

Recommendation 2:

The full data standard should be utilized in subsequent exercises to determine if issues like location/destination cause confusion with full implementation.

Recommendation 3:

Once the EDXL- TEP Standard is accepted, recommend that application developers/managers/vendors have their application tested, evaluated and certified by the NIMS STEP process as conformant with the standard.

Recommendation 4:It is highly recommended that exchange partners utilize a messaging broker such as IPAWS-OPEN or other valid capability for managing message distribution and flow, and to validate messages as conformant with the standard. The messaging broker used (whether IPAWS-OPEN or another capability / product) should incorporate a data validation process to ensure messages comply with the published standard and do not corrupt the databases. Alternatively, if exchange partners choose not to utilize a message broker, recommend that each sending application incorporate message validation into their software, and undergo test and certification by the NIMS STEP process.

Recommendation 5:Recommend that a policy be adopted to utilize a single unique patient identifier throughout the tracking process regardless of jurisdictions involved. During implementation of the data standards, ensure all users and responders understand that the initial triage tag number is the unique identifier for that patient and hence the triage tag must remain with the patient. However, if additional or new identifiers are established during the process, the TEP standard can carry multiple identifiers.

Recommendation 6: Ensure scene or event dashboards are available that have built in triggers that alert event managers when, 1) a patient with triage tag color of “black” is loaded or transported prior to a “red” patient for example, other trigger/alerts should be identified




Objective 5: Assess the ability of the current communication infrastructure to support the efficient exchange of data

Summary of Observed Capability: Two methods of communicating from the hand held input devices were utilized. In one case the hand held computers communicated directly to servers using (3G) cellular data connections. In the other model the hand held devices communicated via wireless (WiFi 802.11x) access points to a laptop computer which was connected to servers through a cellular data connection. Both methods appeared to operate adequately. There were periods of time when it appeared the data connections were lost or slowed.

Consequence:

The ability to communicate data had no significant effect on the data exchange process in this particular location because there was adequate cellular system coverage. There may be areas of poor coverage in future exercises or during actual events.

Analysis:

Cellular data connections are commonly the primary method for connecting field-oriented computers to servers. As patient tracking systems for emergencies become more into practice, other means for connectivity should be investigated. The increasing need and demands for mobile data connections for public safety oriented broad band networks has the attention of the FCC and the communication system community. The expense and questionable reliability of commercial available mobile data networks may preclude some EMS system from full implementation of patient tracking systems. Further investigation is beyond the scope of this exercise.


Recommendation 1:

Work with the FCC and developers of data networks and communications devices to reduce expense and increase the reliability of public safety oriented broadband networks.

Objective 6: Identify strengths and weaknesses of, opportunities for, and threats to full operations of the data exchange process.


The following strengths, weaknesses, opportunities and threats were identified by exercise participants.




StrengthsMultiple systems / vendors, which had never before shared electronic data, were able to quickly and easily share patient tracking data through each step of a patient transport and emergency care continuum. All systems seamlessly updated with the latest status and location of each patient during each part of the exercise.

Weaknesses Vendor plans for application of standards-based information sharing can run counter to competitive business plans. Vendors should be encouraged to follow up through grant requirements and purchase decisions at all levels to drive open standards-based adoption and communication (EDXL and others).

OpportunitiesThe exercise results are excellent vehicles for outreach, marketing and education to other agencies, organizations, jurisdictions and vendors to adopt EDXL standards and plan their use with existing and new communications partners. Additional exercises / EDXL pilots and demonstrations should be planned budgeted for and conducted in different areas of the country. Additional pro-active follow up from each should be pursued so that the excitement and interest generated does not wane and can be funneled into value-add activities which further promote standards adoption. There is also an opportunity to further improve the TEP standard through input gained from this exercise.

ThreatsDue to dynamics and funding constraints, the federal government could decide to support the further development and propagation of this and other EDXL standards. Additionally, business competitive drivers, proliferation of stovepipe solutions and of one-off system to system interfaces for data sharing, which can provide lucrative consulting and profits preventing a culture-shift to open standards-based data sharing.

Consequence:

Efforts in this area have resulted in a workable data standard that allows effective data transfer between systems. However, weaknesses and threats identified during this exercise could derail these efforts to date. If the standard is to be fully successful, the interested parties must continue to use the results and lessons learned from this the exercise to inform the users and vendors of patient tracking systems of the success and convince all parties of the advantages of full implementation and participation.

Analysis:

The OASIS has been successful in promulgating several standards for data exchange. Some have been successfully implemented because all users of the systems have seen the benefit through joint efforts and the leadership of the DHS Science & Technology




Directorate and HHS/ASPR pushed for their requirement. A primary reason for successful implementation was that all federal funding for systems was contingent on the uses of the standard.

However, some continue to hold the perception that the program is yet another Federal Government venture not taking local needs into account; therefore further education and outreach is essential.


Recommendation 1:

The members of the EDXL-TEP Steering Committee should use the results of this exercise to reach out to all system users and educate them on the need for such a standard and garner support for full implementation, with the assistance of state and local “believers” to build credibility with the “feet on the street” and their decision-makers.

Recommendation 2:

DHS S&T, HHS/ASPR, and NASEMSO should complete the process of setting standards through the OASIS process.

Recommendation 3:

DHS, HHS, OASIS and HL7 should continue to collaborate and complete via a formal mechanism, the strategy of use across the pre-healthcare and healthcare facility domains.

Recommendation 4:

DHS-S&T should budget and integrate exercises, pilots and demonstrations into their yearly plan, and integrate a draft standard pilot into their standard process prior to submission to the standards development organization. This provides an opportunity to improve the submission based on real experience, and further promotes interest and support for the ultimate standard.

Recommendation 5:

DHS-S&T should budget and integrate support processes into their program which provide direct support to state, local and regional standards planning, analysis, development and implementation activities to assist in authoritative status and education on the standards, and to assist in alternative methods of conformant implementation of these standards. Multiple support models may be considered from as-needed consulting to direct project-team support.




SECTION 4: CONCLUSION

At the request of the National Association of State EMS Officials (NASEMSO) the Department of Homeland Security, Science and Technology Directorate gathered a steering committee of subject matter experts to develop a draft data standard for patient tracking interchange. Evolution Technologies Inc. was contracted to staff and direct the committee with the goal of developing a standard for submission to the OASIS Standard Development Organization (SDO). As the draft /Emergency Data Exchange Language Tracking of Emergency Patients standard was nearing completion, the steering committee thought it would be beneficial to test the standard in a controlled setting to support the proof of concept as it moved forward to the OASIS acceptance process.

The EDXL-TEP standard was incorporated into a pre-scheduled NDMS reception exercise in Memphis Tennessee. To successfully track 160 patients, 5612 messages were transferred through a messaging broker, DM-OPEN (now “IPAWS-OPEN”), during the exercise. Also during that exercise, specific lessons were learned and recommendations were developed to improve the standard, the various patient tracking vendor applications, and practices to ensure full implementation of the standards. The specific recommendations for improvement have been remunerated in this document and the included improvement plan.

The ultimate goal of the standard and the recommendations for improvement is full implementation of the standard to allow the ability to track the movement of patients in and reunite families during emergencies. An overarching recommendation from the exercise participants was to repeat the exercise to incorporate the improvements and utilize the entire list of data elements in the EDXL-TEP standard. To fully test the standard, future exercises should involve the actual movement of patients from one part of the country to multiple distant patient reception areas and involve multiple commercially-available patient tracking applications. Federally instituted tracking applications including the JPATS and TRAC2ES should also be incorporated. The exercise should be carefully planned and controlled through the use of an experienced exercise control team. The exercise should also include play with family members making calls to their local and federal officials attempting to find their loved ones.

The functionality of the EDXL-TEP standard was proven during this exercise. Improvements to the standard and the means by which the data is transferred are required and further testing is prescribed. Once the data standard is fully implemented it is expected that tracking of patients and the reunification of families will finally be possible regardless of the applications used.




APPENDIX A: IMPROVEMENT PLAN

Objective Recommendation Corrective Action Description

Capability Element

Primary Responsible

AgencyAgency POC

Level of Effort

(Hours)Start Date Completion

Date

Assess the ability of the data exchange architecture to be established in a timely fashion and determine methods to facilitate the process.

Identify the Messaging broker to be utilized to support the exchange of dataDM OPENNational Health Information Exchange NetworkNew Brokering system network

TBD DHS S&T TBD TBD TBD

Once the EDXL-TEP is finalized DHS S&T should publish a data exchange process utilizing DM-OPEN or other messaging broker. DHS should distribute the participation procedures and business to all vendors and managers of patient tracking applications both commercial and government owned/managed.

DHS S&T

Any federal funding, regardless of funding agency, to support patient tracking activities should be contingent on participation with these procedures and compliance with the EDXL-TEP Standards

All Federal Granting Agencies

The Messaging Broker manager technical support should determine the process, procedures and mechanisms to quickly implement patient tracking with “new” partners “on the fly”.


Commercial vendors and managers of government TBD Vendors of

ApplicationsTBD TBD TBD

Appendix A: Improvement Plan For Official Use Only Draft January 18, 2011 31




Capability Element

Primary Responsible

AgencyAgency POC

Level of Effort


Date

owned applications should prepare for the release of the EDXL-TEP and work with the users of the system to allow the seamless implementation of the standard by updating their data elements, preparing exchange messages, and developing a mechanism to quickly turn the data exchange on and off on demand.

The messaging broker needs to have monitoring system to confirm that messages are sent and received from the sending and receiving applications.


Successfully exchange information on 160 patients from the originating system into intermediates systems and to systems tracking patients to the final hospital disposition and update all systems as to the status and location of patients throughout their movement.

Avoid the use of multiple message brokers as it increases the chance of configuration and coding errors. All applications should exchange data directly with the central Message broker


Once the EDXL-TEP standard is finalized repeat the exercise in a more controlled fashion to ensure data exchange is synchronized with the conduct of the exercise play.


Identify obstacles and best practices for

In subsequent exercises associated with the data standards, employ an experienced exercise team






Capability Element

Primary Responsible

AgencyAgency POC

Level of Effort


Date

the implementation of an open data exchange using the EDXL-TEP standard.

that has no vested interest in the success of the standard to plan and conduct the exercise in full accordance with the Homeland Security Exercise and Evaluation Program (HSEEP) and control the flow of activities according to a Master Scenario Events List (MSEL).

Identify any specific changes to the EDXL-TEP that should be incorporated prior to acceptance

Each application developer and manager should review the results of the exercise and determine where they can improve their applications to minimize erroneous date entry.

TBD Participating Vendors

TBD TBD TBD

The full data standard should be utilized in a subsequent exercise to determine if issues like location/destination confusion with full implementation


Once the TEP EDXL Standard is accepted a Conformity Assessment Center should be established so application developers/managers can have their application certified as meeting the standard.

TBD NIMS Support Center

TBD TBD TBD

The messaging broker should incorporate a data validation process to ensure messages do not corrupt the databases.

Messaging Broker

Manager

During implementation of the data standards ensure all users and responders understand that the initial triage number is the unique identifier for that patient and hence the triage tag must remain with the patient.

TBD NASEMSO TBD TBD TBD





Capability Element

Primary Responsible

AgencyAgency POC

Level of Effort


Date

Assess the ability current communication infrastructure to support the efficient exchange of data

Work with the FCC and developers of data networks and communications devices to reduce the expense and increase the reliability of public safety oriented broadband networks.

TBD Public Safety

Advocacy Groups

(NASEMSO, IAFF, IAFC,

etc)

TBD TBD TBD

Identify strengths and weaknesses of, opportunities for, and threats to full operations of the data exchange process.

The members of the EDXL-TEP Sterring Committee should use the results of this exercise to reach out to all system users and educate them on the need for such a standard and garner support for full implementation

TBD EDXT-TEP Sterring

Committee

TBD TBD TBD

DHS S&T and NASEMSO should complete the process of setting the standard through the OASIS process.






Capability Element

Primary Responsible

AgencyAgency POC

Level of Effort


Date

DHS-S&T should budget and integrate exercises, pilots and demonstrations into their yearly plan, and integrate a draft standard pilot into their standard process prior to submission to the standards development organization. This provides an opportunity to improve the submission based on real experience, and further promotes interest and support for the ultimate standard.

DHS S&T

DHS-S&T should budget and integrate support processes into their program which provide direct support to state, local and regional standards planning, analysis, development and implementation activities to assist in authoritative status and education on the standards, and to assist in alternative methods of conformant implementation of these standards. Multiple support models may be considered from as-needed consulting to direct project-team support.

DHS S&T


APPENDIX B:

Proposed EDXL-Tracking of Emergency Patients (TEP) Draft Messaging Specification Elements

To be applied for the2010 NDMS Exercise – Interoperability demonstration

Draft Version 1.1

DHS-Office for Interoperability and Compatibility (OIC) support to the

NDMS Interoperability Exercise

Evolution Technologies, Inc.

April 16, 2010

37 | P a g e

Revision History

Name Date Reason For Changes VersionTimothy Grapes – Evolution Technologies

3/5/2010 Initial Draft for review and Technical Team feedback

0.1

Timothy Grapes – Evolution Technologies

3/11/2010 Incorporated revisions based upon NDMS exercise meeting 3/10/2010

0.2


3/17/2010 Incorporated revisions based upon NDMS exercise meeting 3/16/2010

0.3

Lee Tincher, Tedder Reed, Timothy Grapes – Evolution Technologies

3/23/2010 Draft xsd schema file and xml file representing these requirements incorporated in the document and provided as separate files.Business rules and defaults / enumerated values defined for the exercise.

1.0


4/16/2010 Edits to accurately reflect exercise attributes and participants

1.1

38 | P a g e

Table of Contents1 Introduction 32

1.1 2010 NDMS Patient Movement Exercise 321.2 Proposed EDXL Systems Interoperability Component 321.3 Document Purpose 321.4 Summary 321.5 General Criteria32

2 Structure of the “2010 NDMS Interoperability Exercise - EDXL-TEP Element Reference Model (ERM)” 32

2.1 Technical meeting changes incorporated & defaults / value lists 322.2 Notes from previous technical meetings 322.1 2010 NDMS Interoperability Exercise EDXL-TEP Element Reference Model 32

3 NDMS Exercise TEP XML Model 324 NDMS Exercise XSD Schema 32

39 | P a g e



Chapter 2 IntroductionThis summary describes the overall 2010 NDMS Patient Movement Exercise, and the proposal/plan to incorporate a systems interoperability component into the exercise using the OASIS EDXL DE and HAVE Standards and DHS-sponsored EDXL Tracking of Emergency Patients (TEP) practitioner draft Specification. This document proposes recommended elements from the Draft EDXL-Tracking of Emergency Patients (TEP) Requirements and Draft Messaging Specification, to be applied to the NDMS Interoperability exercise.

2010 NDMS PATIENT MOVEMENT EXERCISE

The NDMS Patient Movement Exercise is an actual exercise using real air and land transport, and volunteer patients driven by objectives of the FCC, federal, State and Local Agencies and NDMS Partner Hospitals. The exercise simulates a hurricane making landfall in Maryland and resulting in 1,000 fatalities and 5,000 people with injuries requiring evacuation to distant healthcare facilities. During the exercise, an actual C-130 transport will land in a triage area prepared to triage, care for, and transport patients to appropriate NDMS medical facilities in Memphis Tennessee.

Participants include responders from the VAMC-Memphis PRT and 164th Airlift Wing, County and State Emergency Management Agencies, Memphis fire and EMS, TN Dept of Health, HHS ASPR, Veterans Administration, TN state National Guard, OHS, TN Dept. of Health, the Maryland Institute for Emergency Medical Services Systems (MIEMSS) and five actual NDMS hospitals receiving patients among others.

Dates: Full Scale Exercise April 28, 2010 (1 day) Nashville, TN Full Scale Exercise (FSE) April 29, 2010 (1 day), Memphis, TN

PROPOSED EDXL SYSTEMS INTEROPERABILITY COMPONENT

A systems interoperability demonstration component is proposed for insertion into the 2010 NDMS exercise.

Proposed Standards to be leveraged: OASIS EDXL Distribution Element (DE) Standard OASIS EDXL Hospital AVailability Exchange (HAVE) Standard DHS-sponsored EDXL Tracking of Emergency Patients (TEP) draft practitioner

Specification, as tailored for this exercise.

Appendix C: Acronyms For Official Use Only Draft October 1, 201040



Objective: Demonstrate notional proof of concept and evaluate limited patient tracking capabilities from Patient Reception Area (PRA) to NDMS hospitals utilizing the Emergency Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Draft Specification, and EDXL-Distribution Element.

Participants: Maryland Institute for Emergency Medical Services Systems (MIEMSS) Tennessee Department of Health Department of Homeland Security Science and Technology Directorate Health and Human Services Department Associate Secretary for Preparedness

and Response Tennessee Emergency Management Agency

Technology Vendors: Disaster Management Solutions – FirstTrak - Patient Tracking EMSystems – HAVE Evolution Technologies, Inc. – NeXt360 Patient Tracking Messaging Broker

services Federal System – JPTAS – Patient Tracking FEMA Disaster Management Messaging Broker services Global Emergency Resources – HC Standard UPP Technologies – Patient Tracking

DOCUMENT PURPOSEIMPORTANT NOTE: This section represents the initial technical specification agreed-upon by the pilot participants. Although the resulting XML schema was developed based upon this information, any differences between this information and the actual XML schema (XSD) used shall refer to the XML schema as normative.

This document proposes recommended elements from the Draft EDXL-Tracking of Emergency Patients (TEP) Requirements and Draft Messaging Specification, to be applied to the NDMS Interoperability exercise. The status of this specification at time of the exercise is draft, during final stakeholder review of the practitioner requirements and design phase, for submission into the public standards development organization process with OASIS. The exercise also utilizes the OASIS EDXL-Distribution Element (DE) for routing of TEP, as well as the EDXL-Hospital Availability Exchange (HAVE).

The purpose of this document is to solicit draft TEP review and comment, in order to gain consensus from the NDMS exercise technical participants for usage of a sub-set and tailoring of TEP elements specifically for the NDMS Exercise Interoperability demonstration.




The intent is to define a minimum set of TEP elements that will simplify and minimize development activities and require no system changes, while meeting the goals for success of the interoperability exercise.

“Final” revisions to this document were made to provide an accurate historical record of the initial phase and planning of this interoperability exercise. However, TEP messaging for the exercise will be guided by the latest xml files provided by the technical support liaison, Lee Tincher under separate cover. This document provided initial guidance and agreement on those basic elements, but the xml is the authoritative document for the technical aspects.

SUMMARY For additional details such as the full draft EDXL-TEP model (for context) and element definitions, please refer to the TEP Requirements and Draft Messaging Specification document previously distributed. Where conflicts exist between that draft specification and this document, this document shall take precedence in guiding development and preparation ONLY for this NDMS interoperability exercise.

The following presents a constrained version of the TEP model showing only those elements proposed for use during the 2010 NDMS Interoperability Exercise. These elements were selected during a conference call held on 03/04/2010, followed by iterative review sessions. Please note that the “Routing Header” (EDXL Distribution Element) is defined in a separate OASIS standard previously provided, used to route TEP, HAVE and other interoperability messages.

A schema file based upon this initial deliverable was developed and accompanied by an example schema representing just the elements agreed upon for this exercise.

GENERAL CRITERIAThe diagram herein represents just those elements proposed for use during this exercise, referred to as a “constraint schema”. This is simply a subset of the standard reference schema which conforms to all the requirements and business rules of the overall TEP reference schema, removing optional elements and defining simplified usage of certain elements such as “location”.

The following are the general attributes of a draft TEP message that are required:

A TEP constraint schema message must NOT be a Proprietary Format. A TEP constraint schema message must comply with the TEP draft standard

unless agreed to put forth into the specification comment period.o A TEP constraint schema message must validate against the TEP draft

specification schema.




o A TEP constraint schema message must use all required elements (i.e. no deletion of required elements are allowed unless agreed to put forth into the specification comment period).

o A TEP constraint schema message must not change attributes for required fields.

The following are recommendations for clarity:

A TEP constraint schema message may further constrain the TEP draft specification schema.

A TEP constraint schema message may add to required element definitions.*(* only to extend or interpret the definition)

A TEP constraint schema message may limit size of required elements. A TEP constraint schema message may exclude optional elements. A TEP constraint schema message may use optional elements in a specific way

– as defined for the exercise.




Chapter 3 Structure of the “2010 NDMS Interoperability Exercise - EDXL-TEP Element Reference Model (ERM)”

The ERM represents a view of the logical structure of the draft TEP standard, to highlight the structure, relationships between the main entities, and proposed elements for this exercise. See the original specification Data Dictionary for additional details. Where conflicts exist between that draft specification and this document, this document shall take precedence in guiding development and preparation ONLY for this NDMS interoperability exercise.

The notes and rules below were agreed-upon through iterative reviews, and will be applied during the NDMS interoperability exercise according to the xsd schema and xml schemas separately provided.

TECHNICAL MEETING CHANGES INCORPORATED & DEFAULTS / VALUE LISTS

IMPORTANT NOTE: This section represents the initial technical specification agreed-upon by the pilot participants. Although the resulting XML schema was developed based upon this information, any differences between this information and the actual XML schema (XSD) used shall refer to the XML schema as normative.

Message Block:

messageID will be system generated, as will systemID

Situation Block:

incidentID - The initial vendor will generate the incidentID, which will be used / carried by subsequent TEP messages

incidentType – Recommend defaulting to the value “Hurricane”

locationLocalName: REMOVED for this exercise

Care Provider Block:

JPATS does not carry Care Provider information at all and has no access to this data. This federal system usage is an exception to the rules and requirements specified by the practitioner groups. For the exercise, the vendor(s) will default/insert mocked up Care Provider information. For the eventual standard, these requirements will be further analyzed and an alternative design explored.




Transport Block:

locationLocalName - REMOVE for this exercise.

“City of Departure” was requested – “current” location within “Patient Encounter” will be used as the departure location when the patient is transferred / transported.

Client Block:

firstName – ADD as an optional element

lastName – ADD as an optional element

Age, Age Units, DOB, and Gender – defined as Optional elements for the exercise. Optionality of these elements is an open issue under standard review at this time.

Gender – Make a defaulted enumerated list including: Male, Female, Other, unknown

Age Units - Make a defaulted enumerated list including: Years, Months, Weeks

Client Encounter Block:

encounterID – This is generated by the originating system

LocationType – Make a defaulted enumerated list including: Incident Scene, Triage area, Evacuation Site, Patient Receiving Area (PRA), Intermediate Care, Tranport Unit, Emergency Department, Hospital, Other

locationLocalName - REMOVE for this exercise

Client Care Record Block:

clientCareRecordID – This is generated by originating system.

triageStatus – Make a defaulted enumerated list (but allow others): Red, Yellow, Green, Black

currentDisposition - Make a defaulted enumerated list (but allow others): Deceased, Deceased and Transported, No Treatment Required, Refused Care, Treated and Released, Treated and Transferred Care, Treated and Transported, Admitted, Treated and Transported to Hospital, Pending/Ongoing.

contaminationRadiationContagonStatus –Optional for the exercise, and as input to the final standard. Make a defaulted enumerated list but allow others: True, False, Unknown.

Client Transfer Block:

Only transferedToDestination (location - text) is required




NOTES FROM PREVIOUS TECHNICAL MEETINGS

1. We will not be utilizing any GML or CIQ elements, in order to simplify the exercise. No “contact” information is proposed for inclusion.

2. Wherever “location” is specified, the following 2 elements are proposed for use:

a. “Location” as a free-form text element. Used to insert such information as the incident lat/long and radius (circle) of the original incident, address info for hospitals (“transferredToDestination in “Client Transfer”). Also available to insert RFID info for Patient real-time tracking or GPS data for vehicle tracking (not recommended to simplify scope).

b. “Location Local Name” where applicable as a free-form text element. This will hold examples such as “Winchester Medical Center”, “Coastal Carolina shoreline”, “Triage site B” or whatever applies.

c. In the “Client Transfer” section, the element name “transferredToDestination” will be used, containing “location” and “Location Local Name” of the patient “transferred to” destination.

2. The thought behind keeping the “Care Provider” elements was that these can be defined up front and defaulted.

3. On the call a valid comment was noted that “clientUniqueIdNumber” may need to allow multiple values, due to different jurisdictions at different phases of patient care and transport may assign their own “uniqueID”. The suggested requirement is for the TEP message to carry these multiple ID’s for tractability purposes. This may require additional attributes such as a Prefix and Source of the ID.

a. However, to simplify the exercise, one and only one “clientUniqueIdNumber” will be utilized.

Boxes on the diagram (“entities”) are used to define message structure by grouping related message elements / tags and defining relationships between blocks of information (represented by lines on the diagrams).

The following key should be referenced in order to read the model.




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

Bold elements are Required. Others are Optional Lines between blocks (i.e. cardinality / number of occurrences of a group of elements)

are read as follows:




2010 NDMS INTEROPERABILITY EXERCISE EDXL-TEP ELEMENT REFERENCE MODEL




Chapter 4 NDMS Exercise TEP XML ModelThe following XML model represents the initial scaled-down TEP message, which was further tailored and used to guide development of the xml (XSD) for the NDMS interoperability exercise. The final and authoritative XML file was provided as a separate file to all participants.

<?xml version="1.0" encoding="UTF-8"?> <tep:TEPStatus xmlns:tep="http://www.example.org/EDXL-TEP-NDMS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.example.org/EDXL-TEP-NDMS EDXL-TEP-NDMS-V1.4.xsd "> <tep:TEPMessage>

<tep:messageID>tep:messageID</tep:messageID><tep:systemID>tep:systemID</tep:systemID><tep:situation> <tep:incidentId>tep:incidentId</tep:incidentId>

<tep:incidentType>http://tempuri.org</tep:incidentType> <tep:incidentLocationType>

<tep:incidentLocation>tep:incidentLocation</tep:incidentLocation>

<tep:clientLocation>tep:clientLocation</tep:clientLocation> </tep:incidentLocationType>

<tep:careProvider> <tep:agencyHospitalNumber>tep:agencyHospitalNumber</tep:agencyHospitalNumber> <tep:agencyHospitalName>tep:agencyHospitalName</tep:agencyHospitalName> <tep:agencyHospitalState>http://tempuri.org</tep:agencyHospitalState> <tep:providerType>http://tempuri.org</tep:providerType> <tep:personnelIdNumber>tep:personnelIdNumber</tep:personnelIdNumber> <tep:personnelState>http://tempuri.org</tep:personnelState> <tep:personnelLevelOfCertificationLicensure>http://tempuri.org</tep:personnelLevelOfCertificationLicensure>




<tep:transport> <tep:unitNumber>tep:unitNumber</tep:unitNumber> <tep:vehicleAgency>tep:vehicleAgency</tep:vehicleAgency> <tep:currentLocation> <tep:streetAddress>tep:streetAddress</tep:streetAddress> </tep:currentLocation> </tep:transport> <tep:careProviderClient> <tep:clientUniqueIdNumber>tep:clientUniqueIdNumber</tep:clientUniqueIdNumber> <tep:gender>http://tempuri.org</tep:gender>

<tep:age>0</tep:age> <tep:ageUnits>http://tempuri.org</tep:ageUnits> <tep:dateOfBirth>2001-12-31T12:00:00</tep:dateOfBirth>

<tep:clientContact><tep:lastName>tep:lastName</tep:lastName><tep:firstName>tep:firstName</tep:firstName>

</tep:clientContact> <tep:clientEncounter> <tep:encounterID>tep:encounterID</tep:encounterID> <tep:encounterDateTime>2001-12-31T12:00:00</tep:encounterDateTime> <tep:ClientEncounterLocationType>

<tep:incidentLocation>tep:incidentLocation</tep:incidentLocation> <tep:localName>tep:localName</tep:localName> </tep:ClientEncounterLocationType> <tep:clientCare> <tep:clientCareRecordDateTime>2001-12-31T12:00:00</tep:clientCareRecordDateTime> <tep:clientCareRecordID>tep:clientCareRecordID</tep:clientCareRecordID> <tep:triageStatus>http://tempuri.org</tep:triageStatus> <tep:clientCurrentDisposition>http://tempuri.org</tep:clientCurrentDisposition> <tep:contaminationRadiationContagionStatus>http://tempuri.org</tep:contaminationRadiationContagionStatus>




</tep:clientCare> <tep:clientTransfer> <tep:destinationTransferredToEta>tep:destinationTransferredToEta</tep:destinationTransferredToEta> <tep:actualArrivalDateTime>2001-12-31T12:00:00</tep:actualArrivalDateTime> <tep:actualDepartureTime>2001-12-31T12:00:00</tep:actualDepartureTime> <tep:transferredToDestination> <tep:clientLocation>tep:clientLocation</tep:clientLocation> </tep:transferredToDestination> </tep:clientTransfer> </tep:clientEncounter> </tep:careProviderClient> </tep:careProvider> </tep:situation>

</tep:TEPMessage> </tep:TEPStatus>




Chapter 5 NDMS Exercise XSD SchemaThe following XSD model represents the initial scaled-down TEP message, which was further tailored and used to guide final development of the xsd for the NDMS interoperability exercise. The final and authoritative XSD file was provided as a separate file to all participants.

<?xml version="1.0" encoding="UTF-8"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/EDXL-TEP-NDMS" xmlns:tep="http://www.example.org/EDXL-TEP-NDMS" elementFormDefault="qualified">

<xsd:complexType name="Status"> <xsd:annotation> <xsd:documentation>Group of TEP Messages</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="TEPMessage" type="tep:TEPMessage" maxOccurs="unbounded" minOccurs="1"></xsd:element> </xsd:sequence> </xsd:complexType>

<xsd:complexType name="TEPMessage"> <xsd:annotation> <xsd:documentation>Group of elements used to uniquely identify a TEP message and its source.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="messageID" type="xsd:string"></xsd:element> <xsd:element name="systemID" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="situation" type="tep:Situation" maxOccurs="1" minOccurs="1"></xsd:element> </xsd:sequence> </xsd:complexType>

<xsd:complexType name="CareProvider"> <xsd:annotation> <xsd:documentation>Group of elements used for identifying and describing a certified care provider (typically Emergency Medical Services personnel).</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="agencyHospitalNumber"




type="xsd:string"></xsd:element> <xsd:element name="agencyHospitalName" type="xsd:string"></xsd:element> <xsd:element name="agencyHospitalState" type="xsd:anyURI"></xsd:element> <xsd:element name="providerType" type="xsd:anyURI"></xsd:element> <xsd:element name="personnelIdNumber" type="xsd:string"></xsd:element> <xsd:element name="personnelState" type="xsd:anyURI"></xsd:element> <xsd:element name="personnelLevelOfCertificationLicensure" type="xsd:anyURI"> </xsd:element> <xsd:element name="agencyHospitalDomainName" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="transport" type="tep:Transport" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="careProviderClient" type="tep:Client" maxOccurs="1" minOccurs="1"></xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Transport"> <xsd:annotation> <xsd:documentation>Group of elements used for identifying and describing a conveyance (vehicle) used to transport a patient.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="unitNumber" type="xsd:string"></xsd:element> <xsd:element name="vehicleType" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="vehicleAgency" type="xsd:string" maxOccurs="1" minOccurs="1"> </xsd:element> <xsd:element name="vehicleState" type="xsd:anyURI" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="currentLocation" type="tep:Location"




maxOccurs="1" minOccurs="0"></xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Location"> <xsd:annotation> <xsd:documentation>Group of elements re-used where required describing a physical location. For TEP used for patient tracking and incident location.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="incidentLocation" type="xsd:string" minOccurs="0"></xsd:element> <xsd:element name="clientLocation" type="xsd:string" minOccurs="0"></xsd:element> <xsd:element name="gpsLocation" type="xsd:decimal" minOccurs="0"></xsd:element> <xsd:element name="streetAddress" type="xsd:string" minOccurs="0"></xsd:element> <xsd:element name="city" type="xsd:anyURI" minOccurs="0"></xsd:element> <xsd:element name="state" type="xsd:anyURI" minOccurs="0"></xsd:element> <xsd:element name="zip" type="xsd:anyURI" minOccurs="0"></xsd:element> <xsd:element name="geospatialData" type="xsd:decimal" minOccurs="0"></xsd:element> <xsd:element name="latitude" type="xsd:decimal" minOccurs="0"></xsd:element> <xsd:element name="longitude" type="xsd:decimal" minOccurs="0"></xsd:element> <xsd:element name="usngReference" type="xsd:decimal" minOccurs="0"></xsd:element> <xsd:element name="legalDescription" type="xsd:string" minOccurs="0"></xsd:element> <xsd:element name="localName" type="xsd:string" maxOccurs="1" minOccurs="0"></xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ClientTransfer"> <xsd:annotation> <xsd:documentation>Group of elements used to describe and track physical movement or transport of a patient.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="destinationTransferredToEta"




type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="actualArrivalDateTime" type="xsd:dateTime" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="actualDepartureTime" type="xsd:dateTime" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="transferredToDestination" type="tep:Location" maxOccurs="1" minOccurs="1"></xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ClientEncounter"> <xsd:annotation> <xsd:documentation>Group of elements used to describe an instance of an encounter between a client (patient) and an EMS Care Provider.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="encounterID" type="xsd:string"></xsd:element> <xsd:element name="encounterDateTime" type="xsd:dateTime"></xsd:element>

<xsd:element name="ClientEncounterLocationType" type="tep:Location" maxOccurs="1" minOccurs="0"></xsd:element>

<xsd:element name="ClientEncounterLocationDescription" type="xsd:anyURI" maxOccurs="1" minOccurs="0"></xsd:element> <xsd:element name="clientCare" type="tep:ClientCare" maxOccurs="unbounded" minOccurs="1"> </xsd:element> <xsd:element name="clientTransfer" type="tep:ClientTransfer" maxOccurs="1" minOccurs="0"> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Situation"> <xsd:annotation> <xsd:documentation>Group of elements used to describe the incident associated with the patient.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="incidentName" type="xsd:string" maxOccurs="unbounded" minOccurs="0">




</xsd:element> <xsd:element name="incidentId" type="xsd:string" maxOccurs="unbounded" minOccurs="1"> </xsd:element> <xsd:element name="incidentType" type="xsd:anyURI"></xsd:element> <xsd:element name="incidentDateTime" type="xsd:dateTime" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="relatedIncidentId" type="xsd:string" maxOccurs="unbounded" minOccurs="0"> </xsd:element> <xsd:element name="incidentLocationType" type="tep:Location" maxOccurs="1" minOccurs="0"></xsd:element> <xsd:element name="careProvider" type="tep:CareProvider"></xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Client"> <xsd:annotation> <xsd:documentation>Group of elements used to uniquely describe the patient.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="clientUniqueIdNumber" type="xsd:string" maxOccurs="1" minOccurs="1"> </xsd:element> <xsd:element name="gender" type="xsd:anyURI"

minOccurs="0"></xsd:element>

<xsd:element name="raceEthnicity" type="xsd:anyURI" maxOccurs="1" minOccurs="0">

</xsd:element> <xsd:element name="age" type="xsd:int"

minOccurs="0"></xsd:element>

<xsd:element name="ageUnits" type="xsd:anyURI" minOccurs="0">

</xsd:element> <xsd:element name="dateOfBirth" type="xsd:dateTime"

maxOccurs="1" minOccurs="0"></xsd:element>

<xsd:element name="personalIdentificationType" type="xsd:anyURI"

maxOccurs="unbounded" minOccurs="0">




</xsd:element> <xsd:element name="personalIdentificationNumber" type="xsd:string"

maxOccurs="unbounded" minOccurs="0"></xsd:element>

<xsd:element name="hairColor" type="xsd:anyURI" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="eyeColor" type="xsd:anyURI" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="distinguishingMarks" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="stateIssuingDriversLicense" type="xsd:anyURI" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="specialTransportation" type="xsd:anyURI" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="nNeeds" type="xsd:anyURI" minOccurs="0"></xsd:element> <xsd:element name="specialMedicalNeeds" type="xsd:anyURI" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="securitySupervisionNeeds" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="familyUnificaionCode" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="specialCommunicationNeeds" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="clientEvacuationStatus" type="xsd:string" maxOccurs="1" minOccurs="0"> </xsd:element> <xsd:element name="clientContact" type="tep:ContactInformation" maxOccurs="1" minOccurs="0">




</xsd:element> <xsd:element name="closestRelativeGaurdian" type="tep:ContactInformation" maxOccurs="unbounded" minOccurs="0"></xsd:element> <xsd:element name="clientEncounter" type="tep:ClientEncounter" maxOccurs="1" minOccurs="0"> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ContactInformation"> <xsd:annotation> <xsd:documentation>Group of elements used to contact a person or persons. Used in TEP for 3 primary purposes: 1 - Client (Patient) contact info; 2 - Patient closest Relative/Gaurdian contact info; and 3 - TEP Message sender.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="lastName" type="xsd:string" minOccurs="0"/>

<xsd:element name="firstName" type="xsd:string" minOccurs="0"/>

<xsd:element name="middleInitial" type="xsd:string" minOccurs="0"/>

<xsd:element name="streetAddress" type="xsd:string" minOccurs="0"/>

<xsd:element name="city" type="xsd:string" minOccurs="0"/>

<xsd:element name="state" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="zip" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="county" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="country" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="telephoneNumber" type="xsd:string" minOccurs="0"/>

<xsd:element name="cellPhone" type="xsd:string" minOccurs="0"/>

<xsd:element name="emailAddress" type="xsd:string" minOccurs="0"/>

<xsd:element name="specialTransportation" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="nNeeds" type="xsd:anyURI"




minOccurs="0"/><xsd:element name="specialMedicalNeeds"

type="xsd:anyURI" minOccurs="0"/><xsd:element name="securitySupervisionNeeds"

type="xsd:boolean" minOccurs="0"/><xsd:element name="familyUnificationCode"

type="xsd:string" minOccurs="0"/><xsd:element name="specialCommunicationNeedds"

type="xsd:string" minOccurs="0"/><xsd:element name="clientEvacuationStatus"

type="xsd:string" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ClientCare"> <xsd:annotation> <xsd:documentation>Group of elements used to describe Care Provider observations, evaluations, electronic measures and actual treatments and procedures taken for or performed on the patient at a particular point in time.</xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element name="clientCareRecordDateTime" type="xsd:dateTime"/>

<xsd:element name="clientCareRecordID" type="xsd:string" minOccurs="1"/>

<xsd:element name="cheifComplaint" type="xsd:string" minOccurs="0"/>

<xsd:element name="systolicBloodPressure" type="xsd:integer" minOccurs="0"/>

<xsd:element name="diastolicBloodPressure" type="xsd:integer" minOccurs="0"/>

<xsd:element name="pulseRate" type="xsd:integer" minOccurs="0"/>

<xsd:element name="respitoryRate" type="xsd:integer" minOccurs="0"/>

<xsd:element name="cardiacMonitorRhythm" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="twelveLeadEcgInterpretaion" type="xsd:string" minOccurs="0"/>

<xsd:element name="pulseOximetry" type="xsd:integer" minOccurs="0"/>

<xsd:element name="co2Level" type="xsd:integer" minOccurs="0"/>

<xsd:element name="bloodGlucloseLevel" type="xsd:integer" minOccurs="0"/>




<xsd:element name="temperature" type="xsd:decimal" minOccurs="0"/>

<xsd:element name="totalGcs" type="xsd:integer" minOccurs="0"/>

<xsd:element name="strokeScale" type="xsd:integer" minOccurs="0"/>

<xsd:element name="thrombolyticScreen" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="medicationsAdministered" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="proceduresPerformed" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="careProviderPrimaryImpression" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="triageStatus" type="xsd:anyURI"/>

<xsd:element name="clientCurrentDisposition" type="xsd:anyURI"/>

<xsd:element name="seriousConcerns" type="xsd:string" minOccurs="0"/>

<xsd:element name="contaminationRadiationContagionStatus" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="acsCdcFieldTraumaCriteria" type="xsd:boolean" minOccurs="0"/> </xsd:sequence> </xsd:complexType>

<xsd:element name="TEPStatus" type="tep:Status"></xsd:element>

</xsd:schema>


HSEEP AAR-IP Template - OASIS€¦ · Web viewThere is unpredictable availability of 3G and 4G...

Documents

Transcript of HSEEP AAR-IP Template - OASIS€¦ · Web viewThere is unpredictable availability of 3G and 4G...