emergency services using interoperability standards

14 March 2010 NCOIC 2010 Plenary Presentation

Emergency ServicesUsing Interoperability Standards


The Goal: Interoperability

Interoperability of Information & Communication Technology (ICT) Services REQUIRE Open, Cost-Free/Low-Cost ICT Interoperability Standards– Data Interoperability REQUIRED: Data Shared Across Applications

– Application Interoperability DESIRED: Component Interoperability such as Contact Information SHOULD be Shareable

Interoperability Across Different Services, Different Jurisdictions– Efficient Distribution of Emergency Communications Within & Across Local,

County-District, State-Province, National, International Boundaries

– Alerts & Warnings

– Resource Logistics & Facilities Documentation

– First-Aid, Triage, Hospital Availability

– Situation Reporting, Incident Command, Decision Support

– Geospatial Information Systems (GIS)



Interoperability Standards should be Reused, not Reinvented– W3C eXtensible Markup Language (XML)

– Open Geospatial Consortium (OGC) Geography Markup Language (GML)

– Organization for the Advancement of Structured Information Standards (OASIS) Common Alerting Protocol (CAP)

– Example Gap: Open Floor Plan Display/eXchange (OFPD/X)

ICT Services Provide Vital Support For Emergency Management Lifecycle– Preparation & Planning

– Response

– Remediation

– Demobilization &

After-Action Analysis



Takeaway: – Right Information to

– Right People

– In the Right Format

– At the Right Time


The Problem

Different Policies, Governance & Vendors/Products Used in Different Jurisdictions

Little or No Interoperability Across Organizational Boundaries– Local, State, National, Tribal and International Jurisdictions– Different Legal Mandates & Jurisdictional Polices Apply in Different

Situations– All Levels may have Different ICT Providers– One-Off Legacy Solutions in Neighboring Jurisdictions with Systems

from the Same Manufacturer may not be Interoperable Few Emergency Management ICT Standards Available & Accepted

– 9/11 Started Change– OASIS Emergency Management Technical Committee (EM TC) CAP

Approved 2004 • Acceptance Difficult until Gov Grant Language Specified Use of CAP• Initial Implementations Experienced Usual Pioneering Problems


The Problem

Little Infrastructure Supporting Service Oriented Architecture (SOA) Across Organizational Boundaries– Web Services & SOA Mostly Confined Inside Enterprise with Single

Vendor Solutions• Same 2004 Starting Timeframe; Pioneering Problems• Early Sample Registries Not Supported so Inadequate Service Visibility

Supporting Standards Lag Behind Hype– Slow to Develop & Often Perceived as Adding Complexity

Combining Interoperability Standards Across Domains a Challenge– Not Invented Here Syndrome– OGC Works With other Standards Development Organizations, Some

OASIS Standards Adopted by ISO, But Problem Remains – Solutions Across Domains Also Needed: Example OFPD/X

• Architecture, Engineering, Contractor (AEC) Standards• ICT Standards• Emergency Management Standards


Realizing the Goal

Use Interoperability Standards in Emergency Services– OASIS Emergency Data Exchange Language (EDXL) Standards Gaining

Traction • DHS-FEMA Integrated Public Alert and Warning System (IPAWS) Developing

National System with CAPv1.2-IPAWS Profile

• CAP and EDXL Distribution Element (EDXL-DE) Specified in All Hazards Alert and Warning (AHAW) Net-Centric Pattern Now in Final Review

– Vendor/Products & Services Can be Tested in National Incident Management System Supporting Technology Evaluation Program (NIMS STEP)

– Mandated Use of Interoperability Standards Means Most Usable Solutions will have Competitive Advantage

Second Generation of EDXL Standards Combines Interoperability Standards– EDXL-DE Use Built into EDXL-Hospital Availability Exchange (EDXL-HAVE;

EDXL Resource Messaging (EDXL-RM)– CAP v2.0 Includes Use of EDXL-DE.– EDXL-DE v2.0 Underway


Realizing the Goal: AHAW

AHAW Pattern uses CAP & EDXL-DE AHAW Pattern Builds SOA Infrastructure AHAW Intended to Exemplify Network Centric Patterns

– Composite Aggregated Services Use Net-Enabled Emergency Response Integrated Project Team (NEER-IPT) Core Services Concept

– Extends Interoperability Standards with Implementation Guidance

– AHAW Technical Pattern (next in line) can Detail How Core Services as well Alert & Warning Services can become NCOIC Building Blocks

AHAW Intended to Exemplify Emergency Services– AHAW Intended to be the Prototype for Emergency Services

Patterns

– Codifying a Systematic Approach


Realizing the Goal: AHAW

AHAW Based on Interoperability Standards– Organization for the Advance of Structured Information Standards

(OASIS) Common Alerting Protocol v1.1 – OASIS Emergency Data Exchange Language Distribution Element

(EDXL-DE) v1.0 – OASIS Reference Model for Service Oriented Architecture v1.0 – Others from Object Management Group (OMG), The Open Group

(TOG), International Organization for Standardization (ISO) Implicit AHAW uses most Net-Centric Services Framework Principles

– Execution Platform Independence– Dynamic Configuration– Explicit Service Scope– Autonomicity– Reuse– Net Centric Data


CAP Standard

CAP Provides a Standard Message Format for Alerts & Warnings

Common Alerting Protocol v1.2 Source: OASIS Standard Common Alerting Protocal v1.2 (approval pending as of 24 August 2009)


EDXL-DE Standard

EDXL-DE Provides Standard Distribution for Emergency Messages

EDXLDistribution distributionID senderID dateTimeSent distributionStatus distributionType combinedConfidentiality language senderRole * recipientRole * keyword * distributionReference * # explicitAddress *

targetArea circle * polygon * country * subdivision * locCodeUN *

contentObject contentDescription contentKeyword * incidentID incidentDescription originatorRole * consumerRole * confidentiality other *

nonXMLContent mimeType size digest uri contentData

xmlContent keyXMLContent embeddedXMLContent

0..*

OR

1

0..*

EDXL-DE v1.0 Document Object Model(Source: OASIS Standard Emergency Data Exchange Language Distribution Element EDXL-DE)


Realizing the Goal:Using Interoperability Standards

You can think of EDXL-DE as an Envelope or Package Containing the Message Payloads of other EDXL Standards


Realizing the Goal:Systematic Methodology

Emergency Services Using Interoperability Standards Should also Build on Net-Centric Principles – Explicitness: Implemented in Service Description– Symmetry: Implemented in Identification of Alert Senders and Recipients– Dynamism: Implemented in the use of SOA Registry-Repositories for

Visibility & Discovery– Globalism: Implemented in the Service Description for Specification of

Policies, Action Model and Process Model– Ubiquitous Access: Implemented in the use of SOA Registry-Repositories for

Visibility & Discovery– Entity Identity Primacy: Implemented in the use of Certification Authorities for

Identity Management – Explicit Relationship: Implemented through Service Description in Policy

Description & Service level Agreements– Scale independence: Implemented in use of Platform and Scale Independent

Open Standards– Pragmatism: Implemented in the Identification of choreography and

Orchestration Constraints for the Integration of Discrete Services


Realizing the Goal:SOA Principle: Visibility

Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and reachability. The initiator in a service interaction MUST be aware of the other parties, the participants MUST be predisposed to interaction, and the participants MUST be able to interact

Source: OASIS SOA-RM: Concepts around Visibility (OASIS Ref Model for SOAs)


Realizing the Goal:SOA Registry-Repositories

SOA Registry-Repositories (SOA-RRs) Provide Visibility

Robust EDXL-DE-Capable Network of Networks using SPORs(Source: NCOIC)


Realizing the Goal:NEER-IPT Core Services

NEER-IPT Core Services & Cloud Computing

– Agency Locator– Identity

Management– Digital Rights

Management

Cloud Computing Storefront is a type of SOA Registry-Repository

(Source: NCOIC)


Realizing the Goal:SOA Service Description

Service Description from SOA-RR is Key to Accessing, Understanding & Invocation of Services

Service Description (Source: Reference Architecture Foundation for SOA v1.0)


Realizing the Goal:Interop Demos: DHS


Realizing the Goal:EDXL-HAVE in Haiti

Sahana Foundation Obtained this Information about the Hospitals and Medical Clinics in Haiti and Published it in XML using EDXL-HAVE

They Lacked Resources to Build an Application to Display the Data in a more Usable Interface, so…



An OASIS EM TC Member Company, Evolution Technologies, Inc. Donated about 5 Total Hours to Adapt their Application & Publish it on the Web

Highlighted Entry is Shown in this Example



Clicking the Highlighted Entry Takes User to this Map-based Location Display



Zooming Normally Shows other Locations or a Street Map

Clicking the Link in the Balloon Pulls Up the HAVE Report for the Facility Represented by its Icon



The Earthquake Left most Facilities Devastated

Most Entries Look like this, but Experience will Equip Response Efforts with the Ability to Create Ad Hoc Locations



This HAVE Report Example Shows How the Data can be Displayed by this kind of Emergency Service, a Service that can be Visible in a SOA Registry for Potential Partners that can Use this Service in a more Complete Composite Application.


Realizing the Goal:Emergency Services Pattern

As Previous Slide Noted, Services can be Aggregated in a SOA that Operates Across Organizational Boundaries

The AHAW Capabilities Pattern is a Good Start NEER-IPT/C3i IPT/Services WG - Overlapping Areas of Interest

in Emergency Services Emergency Services Pattern v. Function-Specific Emergency Patterns?

• Criteria for Choice?• How to Fit in Frameworks?

– NCSF

– NAF



Next Steps Short Term:– AHAW Technical Pattern Planned in NEER-IPT

• Should Services WG and NEER-IPT Work together?

– EDXL-DE Policy Documentation Capability Pattern ?• Distribution of Emergency Messages Need Trusted Networks

– DM OPEN (from DHS Interop Demo slides) Available

– Capabilities Pattern Needed for International Adaptation of EDXL-DE

– NATO Tactical Situation Object (TSO) already uses EDXL-DE

• Trusted Networks Need Documented Actionable Policies• Can be developed with the System Management Framework• Can Pioneer New Capabilities

– Can Work with Existing SQL DBMS with Multiple Condition Clauses and/or

– RDF SPARQL Triple Stores that use EDXL ValueListURNs



Next Steps Longer Term:– EDXL-DE Distribution Services Capability Pattern

• How to use Policy in Distribution• Role-based Access

– EDXL-Emergency Medical Services Pattern• EDXL-HAVE Services Pattern• EDXL-Emergency Medical Patient Tracking Services Pattern

– EDXL-Resource Messaging Services Pattern

– EDXL-Situation Reporting Services Pattern


Credits & Contacts:

Rex Brooks – Individual Consultant– Starbourne Communications Design– OASIS EM TC

• Co-Chair Messages and Notification Subcommittee • Co-Chair Reference Information Model Subcommittee

– OASIS EM Adoption TC• Chair Collateral & documents [email protected]

William Kalin– Command, Control and Interoperability

Science and Technology Directorate Department of Homeland Security

Lee Tincher– CEO, Evolution Technologies, Inc.

[email protected] n

emergency services using interoperability standards

Documents