Where Disaster Response Meets Health Care

1. Where Disaster Response Meets Health Care • Elysa Jones, Chair OASIS • Emergency Management Technical Committee • elysajones@yahoo.com • Werner Joerg, Secretary OASIS • Emergency Management Technical Committee • Werner.Joerg@iem.com

2. Topics • OASIS Overview • Emergency Management Technical Committee (EM-TC) • EM-TC Standards Status • Purpose and Background • TEP Background • Specification Efforts to consider for Collaboration • Discussion Q&A • Next Steps

3. OASIS Overview • Organization for the Advancement of Structured Information Standards www.oasis-open.org • Technical Committees • International • Open • Free

4. Emergency Management Technical Committee • Structure • Initial Subcommittees: Message and Notification (CAP, RM, SitRep); Geospatial; Infrastructure Framework (DE); • Additional Subcommittees: Reference Information Model; Hospital Availability, Tracking of Emergency Patients; Common Alerting Protocol • Emergency Data Exchange Language • Family of Standards to support the emergency management community. DHS Science and Technology Office of Interoperability and Compatibility

5. Practitioner Driven Process Practitioner Requirements Draft Requirements Message Design Specification Vendor Reviewed Requirements and Recommendations Internationally Recognized Standard Practitioner Steering Group (PSG) Standards Working Group (SWG) Scenario Teams Emergency Interop Consortium (EIC) OASIS Customers Domain Practitioners Local, State & Federal Government Industry - Product Providers

6. Emergency Data Exchange Language (EDXL) Standards OASIS EM Standards are grouped under the EDXL Suite EDXL-CAP Common Alerting Protocol + Profiles (IPAWS, CAP-AU, ..) v1.0 - 2004, v1.1- 2005, v1.2 – 2010 (v2.0 in progress) EDXL-DE Distribution Element v.1.0 - 2006 (v2.0 in progress) EDXL-HAVE Hospital AVailability Exchange v1.0 - 2008 (v2.0 in progress) EDXL-RM Resource Messaging v1.0 - 2008 EDXL-SitRep Situation Reporting v1.0 in progress (expected Q4 2012, Q1 2013) EDXL-TEP Tracking Emergency Patients v1.0 in progress (expected Q1 or Q2, 2013) EDXL-RIM Reference Information Model

7. Integrated Emergency Management • Integrated means all parts of Emergency Management work together as a whole • OASIS supports structured information standards – our emphasis: • Information & Communication Technology (ICT) • Service Oriented Architecture (SOA) • ICT & SOA support End-to-End (continuous) Emergency Management Lifecycle as part of Smart Grid

8. Integrated Emergency Management MITIGATE PREPARE RECOVER RESPOND

9. Purpose • Background • In a disaster or emergency situation, there is a clear need for hospitals to be able to communicate with each other, and with other members of the emergency response community. The ability to exchange data in regard to hospitals’ bed availability, status, and capacity enables both, the hospitals and the other emergency agencies, to respond to emergencies or disaster situations with greater efficiency and speed. • Collaboration • OASIS and HL7 signed a Collaboration Agreement in July 2011 due to a mutual desire to serve cross-profession practitioner communities. These communities include the unique cross domain interoperability required for Emergency Responders and Emergency Departments to effectively and efficiently serve the “Continuum of Care” of emergency patients. We desire to minimize potential confusion for standards implementers, and avoid potential inconsistencies and unplanned overlaps between developed and published standards within each domain.

10. Tracking of Emergency Patients (TEP) Messaging Standard Presented to the Senior Leadership Council on Patient Movement October 20, 2011

11. What is the Tracking of Emergency Patients (TEP) Standard? An Open, Public Standard for Data Exchange • One of the Emergency Data Exchange Language suite of data exchange standards • Emergency / Healthcare Practitioner-Driven: federal, state, local • Co-sponsored publication – OASIS and HL7 • HHS may offer incentives for implementation

12. Purpose of TEP • Pre-Hospital Patient Movement, Condition, Care and Status • Tracking from professional first responder emergency encounter across the emergency care continuum; to ”hand-off” to definitive care facilities. • Supports Hospital Evacuations • Provides Common Operating Picture • Facilitates Collaboration and Coordination

13. TEP Context - Continuum of Patient Movement EDXL-TEP (Pre-Hospital) HL7 In-Hospital HL7 Hospital to Hospital and Other (e.g. Labs) EDXL-HAVE Emergency Hospital Availability Exchange Emergency Response Emergency Management State, Local, Federal ESF-8

14. AHRQ & TEP Standard Core Elements PATIENT TRACKING

15. How Did It Start? • The Office of the National Coordinator (ONC) identified gaps across a broad continuum of care: • IS-04 Emergency Responder Emergency Health Record (ER-EHR) & Use Cases • HITSP (Health Information Technology Standards Panel) ER-EHR Interoperability specification. • ONC with HITSP moved gap closure efforts to 4 organizations: • The HIMSS “Integrating the Healthcare Enterprise” (IHE) • HITSP for additional gap identification and analysis • HL7 for Standards (in-hospital, hospital to hospital, and between hospital with other care providers, labs, etc.) • DHS S&T with OASIS (in partnership with HL7) for emergency / pre-hospital Standards • Development of a consensus-based messaging standard for cross-agency and profession patient tracking

16. What TEP is NOT • Not a message routing solution • Not addressing all components required for a complete implementation architecture • John Quinn, HL7 CTO • Mike Glickman - HL7, HIMSS and HITSP facilitator • Elysa Jones, OASIS EM-TC chair • John Halamka, Co-Chair of the HIT Standards Committee • Stephen Hufnagel, Military Health Services • Sally Phillips, AHRQ (at that time) and Christy Music, DoD OASD • Dr. Greg Mears (UNC Chapel Hill EMS Medical Director), Kevin McGinnis (NASEMSO), Clay Mann (University of Utah School of Medicine), John Donohue (MIEMSS), Paul Petersen (TN DOH Emergency Preparedness), Knox Andress (Louisiana Region 7 Hospital Preparedness) Helping to connect the dots…

17. How Did DHS Get Involved? • National Association of State EMS Officials (NASEMSO) • ONC HITSP ER-EHR IS04 • NEMSIS • AHRQ Recommendations for a National Mass Patient and Evacuee Movement, Regulating, and Tracking System • DoD OASD • DHS S&T was requested to facilitate cross-org TEP requirements – applying the EDXL practitioner cross-org consensus process • Messaging Standard only – not Transport • Vocabulary Harmonization w/HL7 via NEMSIS • Requirements submitted to an SDO • DHS has no dog in the fight

18. Patient Tracking Collaboration History 2003 - 2006 2007 2008 2009 2010 2011 2012 NHTSAEMS Data Set1994 NEMSIS 3 (HL7 Compliant) NEMSIS EMS Request toDHS S&T Multiple States/Locals Collaborate on Patient Tracking Request to NASEMSO TEC Rqmts Begin OASIS / HL7 TEP TEP Rqmts Begin OASIS EDXL CAP 1.0 DHS OASIS DE 1.0 OASIS HAVE 1.0 OASIS HAVE 2.0 OASIS / HL7 MOU AHRQ Nat. Mass Pt & Evac AHRQ Work begins: Nat. Mass Pt & Evac. ONC HITSP ER-EHR IS04& Use Cases HHS HHS HAvBedPILOT DHS, states, HHS-NDMS Meeting2011 HHS HAvBed2 HITSP, HL7, DHS, OASIS (Baltimore) HITSP, HIMSS, HL7, OASIS (DC) TEP briefing to the Sr. Leadership Council on PT2011 JPATS TRAC2ES DoD TEP briefing to HHS-ONC JPTA

19. What Tracking Systems are Targeted for TEP?How will the message be sent and received? • Open, Public Standard. No Mandates. • Driven solely by the practitioners, agencies and organizations • Many local and state Patient Tracking systems are implemented, but they do not share information between them or with JPATS • TEP can be utilized without changes to core systems • TEP can be used over different “transport” mechanisms as needed • 2010 and 2011 NDMS live patient movement exercises (TEP Proof of Concept) between multiple disparate systems: • Utilized the FEMA IPAWS (OPEN) message broker as a convenient method for the exercise. • But, any network, message broker, middleware or other mechanism may be utilized, such as PHIN-MS or a “network of networks” • Draft TEP Standard implementation effort was relatively low

20. How does TEP link with ESF #8 and JPATS • As state resources become stressed and request federal assistance, TEP is intended to fulfill pre-hospital data exchange requirements for cross-system patient tracking, including: • State systems, and localities systems within those states • JPATS patient movement data shared with state and local systems • TEP data exchange facilitates an end to end view of pre-hospital patients across all touch points • If desired, TEP data can be used by applications to assist with missing persons, family notification and reunification information.

21. How does TEP link with NMETS and Mass Care? • Initial scope addressed both patient tracking, as well as tracking of non-medical evacuees, self-evacuees and those sheltering in place. • Standards requirements are being defined in 2 phases: • Patient tracking requirements (TEP) • “Client” tracking requirements - “Tracking of Emergency Clients” effort (TEC). • Mass Care directly benefits from TEP-based sharing of patient location, condition and care information. • FEMA, developers of NMETS (the National Mass Evacuation Tracking System) are TEC steering committee members (with many others), to ensure NMETS data exchange requirements are met • Requirements cover data-sharing for patient tracking, and non-medical evacuees, attendants and care givers.

22. Backup Slides

23. Local State Destination Site DoD Air Transport Hospital / FMS Pre-Hospital Continuum of Patient Movement “3 Simple Use Cases” In-Transit Visability Origination / Disaster Area 1 – Simple / Local Ground Transport Destination Site / Hospital Patient Transport Begins Origination / Disaster Area 2 – Local Mass Casualty & Intermediate Sites Destination Site / Hospital Patient Transport Begins Field Hospital Federal / ESF-8 NDMS / JPATS NDMS / JPATS Origination / Disaster Area 3- Ground / Air Transport Patient Transport Begins APOE APOD

24. NDMS Hospital NDMS Hospital Local Hospital Local Hospital Evacuation Patient Receiving Area (PRA) 2010 TN NDMS Patient Movement & Draft EDXL-TEP Patient Tracking POC Maryland (MIEMSS) 1- Tag and Transport patient to NDMS DMAT at BWI Thurgood Marshall Airport Begin tracking patients via DE-TEP (100 Patients for on-load to air transport. To be moved by NDMS to another State for Hospitalization and/or Treatment) EMSystems EDXL-HAVE HC Standard COG 6977 (GER911) TNCRN/WebEOC (No Message Exchange via DM OPEN) HC Standard COG 6977 (GER911) DE-TEP IPAWS OPEN …Hospitals provide HAVE updates 2 – Load patients to aircraft and provide TEP updates (JPATS update all) Patient Tracking COG 6974 (Tennessee UPP) IPAWS OPEN DE-HAVE WebEOC JPATS COG 6978 (Apprio) DE-TEP DE-TEP First Track COG 6975 (DM Solutions) Tennessee – Memphis Shelby: 3 -Offload patients from aircraft (First Track update all) 4 - Patient ambulance transport (First Track update all) Take-off Landing IPAWS OPEN First Track COG 6975 (DM Solutions) HAVE COG 6976 (EM Systems) DE-TEP 5 – Patients received at hospitals (First Track update all) DE-TEP Updates IPAWS OPEN

25. 2011 Louisiana NMDS Patient Movement Exercisedraft TEP Message Exchanges

26. Tracking of Emergency Patients Scope

27. EDXL-HAVE Overview • Derived from HaveBed • Allows Emergency Managers to make sound logistic decisions on where to route victims • An XML document format to enable information exchange about a Hospital’s • Status & Services • Resources (incl. bed capacity, Emergency Department status, available service coverage) • First “big” test: Haiti 2010 • Experience / Evaluation → HAVE 2.0 (~2013)

28. EDXL-HAVE Overview • Features: • Multiple use – EDXL HAVE provides a flexible format which can be used during disasters, everyday emergencies, reporting etc • Benefits: • Easy to implement • Promotes well structured messages • Extensible and adaptable • Adoption: • Basis for HHS’ HAvBED reporting requirements • A number of state/regional hospital associations

29. EDXL - HAVE Origins To support a Department of Health & Human Services (HHS) mandate, the Assistant Secretary of Preparedness and Response (ASPR) has established the Hospital Available Beds for Emergencies and Disasters (HAvBED) system, a near real-time view of the national healthcare system in an effort to enhance the public health situational awareness capability • The HAvBED web service provides a way to automate data submission with different existing systems. • Limitations with current HAvBED communication schema include the following: • Adds time to planning and implementation • Not peer reviewed • Compatibility issues • Irregular or No Maintenance Adoption of the EDXL-HAVE addresses all limitations with the HAvBED communication schema

30. EDXL-HAVE Structure • <xsd:element name="Hospital" …> • container element for reporting status of a hospital. • <xsd:element ref="Organization"> • container element for organization information elements - refers to the entity that is • providing the data. This generic name is used throughout this document. Typically, • this will include hospitals, nursing care centers, trauma centers etc. • <xsd:element name="EmergencyDepartmentStatus" …> • Report on the emergency department status for the organization • <xsd:element name="HospitalBedCapacityStatus" …> • The hospital bed capacity for the organization • <xsd:element name="ServiceCoverageStatus" …> • The physician service coverage status for the organization • <xsd:element name="HospitalFacilityStatus" …> • The status of operations for the organization • <xsd:element name="HospitalResourcesStatus" …> • The status of resources for the organization • <xsd:element name="LastUpdateTime" …> • The last time the information was updated • … • </xsd:element>

31. EDXL-SitRep Overview • Exchange clear, well-defined information for accurate, well-informed decisions • Choice of preconfigured reports and ad hoc forms • An XML document format to report on incidents • From brief observations of limited locations • To full scale planning for response to large scale disasters

32. EDXL-SitRep Structure

33. EDXL-SitRep Structure

34. EDXL-SitRep Structure

35. EDXL-TEP Overview • Tracking patients across the Emergency Medical Service (EMS) and Emergency Medical Care continuum • Including hospital evacuations and day-to-day patient transfers • An XML document format for exchange of • Emergency patient and tracking information • during encounter through admission or release

37. EDXL-TEP Structure

38. EDXL-TEP Structure

39. EDXL-TEP Structure

40. EDXL – DE Overview EDXL-DE facilitates the packaging of content and provides a standard set of elements in a header to describe that content in order to facilitate message delivery. • Features: • Ability to package both XML and binary data • Ability to use region-specific terminology • XML with Digital Signature and encryption support • Transport and system independent • Simple to use, ability to scale

41. EDXL – DE Overview • Benefits: • Easy to implement • Promotes well structured messages • Extensible and adaptable • Adoption: • FEMA DM – OPEN Platform • Misc. Operational Information Sharing Pilots • DHS DNDO messaging • Next-generation EAS / IPAWS

42. EDXL – DE Structure

43. EDXL-RIM Overview • The purpose of the EDXL-RIM specification is to provide a high-level, abstract, information model for the family of EDXL specifications. EDXL-RIM is intended to be a unifying reference for future versions of existing specifications and for the next member specifications of this family group • A simpler approval process

44. EDXL-RIM will include • XML Schema for common terminology definitions and datatype • RDF Schema to establish simple core relationships, e.g. that a 'target area' is a member of the 'geospatial information' category; and, • OWL ontology to establish the logical relationship of concepts involved in EDXL, e.g. that schedule information is the union of geospatial information with resource deployment information and temporal information. • Reference to a common data dictionary and governance for usage/change.

45. EDXL-RIM Elements • Reusable elements • edxl-ct: CommonTypes / supportingElements • edxl-gsf: GML Simple Features (GSF) Profile • edxl-ciq: Customer Information Quality (CIQ) Profile • Ontology • … a work in progress