230 likes | 377 Views
COPS 2007 Technology Program Kickoff Conference. How to Build Stakeholder Consensus. Tim Grapes – Evolution Technologies, Inc. tgrapes@evotecinc.com http://www.evotecinc.com. Stakeholder Consensus Standards Development Process.
E N D
COPS 2007 Technology Program Kickoff Conference How to Build Stakeholder Consensus Tim Grapes – Evolution Technologies, Inc. tgrapes@evotecinc.com http://www.evotecinc.com
Stakeholder Consensus Standards Development Process – Cont. • Practitioners: Requirements • Research – Other standards & efforts (e.g. NIMS/ICS, GJXDM, IEEE 1512, ARMS, ROSS, PHIN…) • Standards Working Group – iterative approach • Scenario/“Use Case” subcommittees • Draft specification – Message definition • EIC • Public Standards Development Organization • NIEM • Review and approve for reuse by COI Authoritative Source
The “IEPD Consistency” Problem Definition: Two groups independently developing IEPDs for the same purpose will create incompatible IEPDs. Result: • “Stovepipe” exchanges that meet only narrow system to system requirements • Small-scale interoperability between coordinating partners… • …but not large-scale interoperability between independent community members (i.e., the ultimate promise of standards)
NIEM Data Dictionary By Itself Is Not Enough For Information Exchanges • An Information Exchange Package (IEP) begins with a business need for a particular exchange. • IEP Documentation (IEPD) describes how that exchange should be expressed using NIEM. • The IEPD is a key point for introducing new semantic elements to NIEM and for reusing existing ones. • An IEPD itself can also be reused in whole or in part to speed development and lower the cost of sharing information.
Solutions • Broad practitioner requirements and prioritization • (i.e. Practitioner Steering group and Standards Working group) • Public standards body vetting and development • (i.e. OASIS) • Authoritative COI standards approving body • (i.e. NIMS)
Practitioner Driven • Currently working with DHS DM and facilitating a broad representation of practitioners in our Practitioner Steering Group. • Practitioners have supplied technical resources for scenario and use case development in our Standards Working Group
Practitioner DrivenLevels of Participation • Provide input on priorities / Recommend new standards • Participate in Standards Working Group • Scenario / Use Case teams • Review requirements and draft specification • Participate on OASIS TC • Participate in OASIS public comment • Participate in pilots and demonstrations
Practitioner Driven • A scenariodescribes a potential incident or set of events and its response, step by step over time. The scenario is used to demonstrate application or typical uses of the Situation Reporting Messaging Standard from an end-user perspective. • A use case represents some potential uses of the Standard within the scenario. The process drives out requirements and Information that needs to be exchanged. • Existing documents, forms etc. may or may not be used in the development of use cases.
Standards Development Organization (SDO) Organization for the Advancement of Structured Information Standards (OASIS) OASIS is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. OASIS Emergency Management Technical Committee key product: • The Emergency Data Exchange Language (EDXL)
Emergency Data eXchange Language (EDXL) • Suite of messaging standards with technical rules governing how incident-related information is packaged for exchange • Cannot change every system / database to “speak the same electronic language.” • XML-based, not data standards; Practitioner and business process-driven EDXL Implementation • Systems are updated to receive and send information using these standards. • Information is displayed in the native system in a user-friendly format • Open Application Programming Interfaces • EvoTec works closely with the vendor community for effective implementation
EDXL – Approved Messaging Standards • Common Alerting Protocol (CAP) • CAP v1.1 was adopted as a standard on October 1, 2005. • CAP provides the ability to exchange all-hazard emergency alerts, notifications, and public warnings, which can be disseminated simultaneously over many different warning systems (e.g., computer systems, wireless, alarms, TV, radio) • CAP is being implemented in IPAWS – the Integrated Public Alert & Warning System DHS/FEMA effort • CAP was recommended for acceptance with the International Telecommunications Union (ITU) for a global alerting standard • May 31, 2007 - The Federal Communications Commission adopted an Order that requires Emergency Alert System (EAS) participants to accept messages using Common Alerting Protocol (CAP), the groundwork for Next Generation EAS delivery systems..
EDXL – Approved Messaging Standards • Distribution Element (DE v1.1) • DE 1.0 was adopted as a standard in April 2006. • DE provides a flexible message-distribution framework for data sharing in emergency information systems. • Among others,DE has been implemented in the DHS/FEMA effort IPAWS – the Integrated Public Alert & Warning System
EDXL - DRAFT Messaging Standards • Hospital AVailability Exchange (HAVE): • HAVE was submitted to OASIS in January 2006. • HAVE provides standard exchange of hospital status, capacity, and resource availability between medical and health organizations and emergency information systems. • OASIS adoption is expected in late 2007/Jan 2008. • Resource Messaging (RM) – 16 standard messages: • RM was submitted to OASIS in January 2006 and supports a pilot for National Capital Region Data Exchange Hub. RM provides standard exchange of resource information (persons or things) needed to support emergency and incident preparedness, response, and recovery. • OASIS adoption is expected in late 2007/Spring 2008 • Situation Reporting Standard: • Situation Reporting addresses information gathered from a variety of sources, that provides a basis for incident management decision making. It provides information on the current situation, the operational picture, and current response and resources in an actionable form.
Authoritative COI Standards Approving Body • MOU in progress between DHS DM, NIEM and NIMS • DHS DM will: • Utilize NIEM as development Data Dictionary • Utilize NIEM NDR for element/attribute extension requests • Utilize and Update the NIEM EM Domain via governance established by NIEM • NIEM will: • Provide final Naming and Design Rules (NDR) • Provide governance for change management to include processes for addition/deletion/modification of EM Domain elements and attributes • Provide IEPD Repository • NIMS will: • Evaluate proposed standards for adoption into “NIMS Approved” Messaging Standards • Require NIEM compliancy for all “NIMS Approved” Messaging standards. • Publish to NIEM IEPD Repository with XML Messages for community re-use.
Summary – Building Stakeholder Consensus • Practitioner-Driven • Open, Public Process • Cross-Profession • State, Local, Federal, Industry • Federal Alignment & Grants • Varied Levels of Participation • Non-Biased Facilitation - No Dog in the Fight • Sharing / re-use of standard
Contact Information Tim Grapes tgrapes@evotecinc.com http://www.evotecinc.com