Where Disaster Response Meets Health Care

Where Disaster Response Meets Health Care

Elysa Jones, Chair OASIS

Emergency Management Technical Committee

[email protected]

Werner Joerg, Secretary OASIS

Emergency Management Technical Committee

[email protected]

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

OASIS Overview

• Organization for the Advancement of Structured Information Standards www.oasis-open.org

• Technical Committees

• International

• Open

• Free

• StructureInitial 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 LanguageFamily of Standards to support the emergency management community.

DHS Science and Technology Office of Interoperability and Compatibility

Emergency Management Technical Committee

Practitioner Steering Group(PSG)

Standards Working

Group (SWG)

Scenario Teams

Emergency Interop

Consortium (EIC)

OASIS Customers

Practitioner Requirements

Draft Requirements Message Design

Specification

Vendor Reviewed Requirements and Recommendations

Internationally Recognized

Standard

Domain Practitioners

Local, State & Federal GovernmentIndustry - Product Providers

Practitioner Driven Process

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 Elementv.1.0 - 2006 (v2.0 in progress)

• EDXL-HAVE Hospital AVailability Exchangev1.0 - 2008 (v2.0 in progress)

• EDXL-RM Resource Messagingv1.0 - 2008

• EDXL-SitRep Situation Reportingv1.0 in progress (expected Q4 2012, Q1 2013)

• EDXL-TEP Tracking Emergency Patientsv1.0 in progress (expected Q1 or Q2, 2013)

• EDXL-RIM Reference Information Model

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

Integrated Emergency Management

PREPARE

RESPONDRECOVER

MITIGATE

Purpose

• BackgroundIn 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.

• CollaborationOASIS 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.

Presented to the Senior Leadership Council on

Patient MovementOctober 20, 2011

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

What is the Tracking of Emergency What is the Tracking of Emergency Patients (TEP) Standard?Patients (TEP) Standard?

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

Purpose of TEPPurpose of TEP

EDXL-TEP

(Pre-Hospital)

TEP Context - Continuum of Patient MovementTEP Context - Continuum of Patient Movement

HL7

In-Hospital

HL7

Hospital to Hospital and Other

(e.g. Labs)

EDXL-HAVEEmergency

Hospital Availability Exchange

AHRQ & TEPAHRQ & TEPStandard Core ElementsStandard Core Elements

PATIENTTRACKING

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:

1. The HIMSS “Integrating the Healthcare Enterprise” (IHE)

2. HITSP for additional gap identification and analysis

3. HL7 for Standards (in-hospital, hospital to hospital, and between hospital with other care providers, labs, etc.)

4. 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?

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

o National Association of State EMS Officials (NASEMSO)

o ONC HITSP ER-EHR IS04o NEMSISo AHRQ Recommendations for a National

Mass Patient and Evacuee Movement, Regulating, and Tracking System

o DoD OASD

Patient Tracking Collaboration HistoryPatient Tracking Collaboration History

Multiple States/Locals Collaborate on

Patient Tracking

JPTA

OASIS / HL7 TEP

Request to

NASEMSO

OASIS EDXL

CAP 1.0

JPATS

AHRQ Nat. Mass Pt

& Evac

HHS HAvBed2

OASIS HAVE

1.0

HHS HAvBedPILOT

NEMSIS 3 (HL7 Compliant)

NEMSIS

OASIS DE 1.0

Request to

DHS S&T

OASIS / HL7 MOU

TRAC2ES

2003 - 2006 2007 2008 2009 2010 2011

TEC Rqmts Begin

HITSP, HIMSS, HL7, OASIS (DC)

ONC HITSP ER-EHR

IS04& Use Cases

TEP Rqmts Begin

HITSP, HL7, DHS, OASIS (Baltimore)

EMS

DoD

HHS

DHS

NHTSAEMS Data Set

1994

AHRQ Work begins: Nat. Mass

Pt & Evac.DHS, states, HHS-

NDMS Meeting2011

TEP briefing to the Sr. Leadership Council on PT

2011

TEP briefing to

HHS-ONC

OASIS HAVE 2.0

2012

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.

23

Origination / DisasterArea

Local

Patient Transport Begins APOE APOD

DoD Air Transport

NDMS /

JPATS

DestinationSite

Hospital / FMS

3- Ground / Air Transport

State

Pre-Hospital Continuum of Patient Movement“3 Simple Use Cases”

NDMS /

JPATS

Origination / DisasterArea

Patient Transport Begins

DestinationSite / Hospital

1 – Simple / Local Ground Transport

Federal / ESF-8

Origination / DisasterArea

Patient Transport Begins

DestinationSite / Hospital

2 – Local Mass Casualty & Intermediate Sites

Field Hospital

24

EvacuationPatient Receiving Area (PRA) 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)

DE-TEPDE-TEP

JPATSCOG 6978(Apprio)

JPATSCOG 6978(Apprio)

IPAWSOPEN

IPAWSOPEN

First TrackCOG 6975

(DM Solutions)

First TrackCOG 6975

(DM Solutions)

Patient TrackingCOG 6974

(Tennessee UPP)

Patient TrackingCOG 6974

(Tennessee UPP)

HAVECOG 6976

(EM Systems)

HAVECOG 6976

(EM Systems)

HC StandardCOG 6977(GER911)

HC StandardCOG 6977(GER911)

DE-TEPDE-TEP

2 – Load patients to aircraft and provide TEP

updates (JPATS update all)

Tennessee – Memphis Shelby:3 -Offload patients from aircraft (First Track update all)4 - Patient ambulance transport (First Track update all)

DE-TEPDE-TEPLocalHospital

NDMSHospital

NDMSHospital

LocalHospital

EMSystemsEDXL-HAVE

TNCRN/WebEOC(No Message

Exchange via DM OPEN)

5 – Patients received at

hospitals (First Track update all)

First TrackCOG 6975

(DM Solutions)

First TrackCOG 6975

(DM Solutions)IPAWSOPEN

DE-TEPDE-TEP

IPAWSOPEN

DE-TEP UpdatesDE-TEP Updates

Landing

Take-off

WebEOCWebEOCDE-HAVEDE-HAVE

…Hospitals provide HAVE

updates

HC StandardCOG 6977(GER911)

HC StandardCOG 6977(GER911)

2010 TN NDMS Patient Movement &

Draft EDXL-TEP Patient Tracking POC

®

2011 Louisiana NMDS Patient Movement Exercise2011 Louisiana NMDS Patient Movement Exercisedraft TEP Message Exchangesdraft TEP Message Exchanges

25

Tracking of Emergency Patients ScopeTracking of Emergency Patients Scope

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)

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

EDXL - HAVE Origins

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

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

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>

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

EDXL-SitRep Structure

EDXL-SitRep Structure

EDXL-SitRep Structure

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

EDXL-TEP Structure

EDXL-TEP Structure

EDXL-TEP Structure

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

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

EDXL – DEStructure

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

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.

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