Emergency Services Using Interoperability Standards

1. Emergency ServicesUsing Interoperability Standards

2. 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)

3. The Goal: Interoperability • 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

4. The Goal: Interoperability • Takeaway: • Right Information to • Right People • In the Right Format • At the Right Time

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

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

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

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

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

10. 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)

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

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

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

14. 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)

15. Realizing the Goal:SOA Registry-Repositories • SOA Registry-Repositories (SOA-RRs) Provide Visibility Robust EDXL-DE-Capable Network of Networks using SPORs (Source: NCOIC)

16. 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)

17. 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)

18. Realizing the Goal:Interop Demos: DHS

19. Realizing the Goal:Interop Demos: DHS

20. Realizing the Goal:Interop Demos: DHS

21. Realizing the Goal:Interop Demos: DHS

22. Realizing the Goal:Interop Demos: DHS

23. Realizing the Goal:Interop Demos: DHS

24. 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…

25. Realizing the Goal:EDXL-HAVE in Haiti • 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

26. Realizing the Goal:EDXL-HAVE in Haiti • Clicking the Highlighted Entry Takes User to this Map-based Location Display

27. Realizing the Goal:EDXL-HAVE in Haiti • 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

28. Realizing the Goal:EDXL-HAVE in Haiti • 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

29. Realizing the Goal:EDXL-HAVE in Haiti • 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.

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

31. Realizing the Goal:Emergency Services Pattern • 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

32. Realizing the Goal:Emergency Services Pattern • 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

33. 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 Subcommittee rexb@starbourne.com • William Kalin • Command, Control and InteroperabilityScience and Technology Directorate Department of Homeland Security • Lee Tincher • CEO, Evolution Technologies, Inc. ltincher@evotecinc.com n