Hi Michelle,
Sorry I couldn't get back to this earlier today,
but I will definitely be able to compose some
pointed discussions on the paper's potential. My
primary object will be to connect these positions
to the need for an Emergency Mgt AND Health
Informatics Information Sharing and Analysis
Center (an ISAC).
If you can spare some time early Sunday morning,
I will call you then, or you can attempt to get a
conference call together. The kind of ISAC I am
exploring would embody the SOA2eGov(& eBIZ)
connection, having appropriate levels of
accessibility (access control). The initiation of
work toward a "Situational Awareness"
specification, as well as or in addition to the
"Cursor On Target" work currently being sounded
out in various circles. Their are a lot of
aspects to the discussion you have initiated
below that fit into many areas of the work I, and
the collaboratory we have built over the last
year and half, have in progress.
Cheers,
Rex
At 1:36 PM -0600 12/15/06, Michelle Raymond wrote:
>Below is fodder for a position paper (1000 - 2000 words. If folks
>feel I'm heading in a misguided direction, chime in. Actually, chime
>in anyway. Any other perspectives would likely be a positive
>influence and better direct the resulting paper and presentation. The
>paper must go in today. Then we'll have some time to iron out the
>presentation (if the paper is accepted.)
>
>I've attached snippets from existing documents. Obviously, they don't
>tell a cohesive story as is. I'll begin working it together now.
>Send comments via email and/or call my cell #: 612 703 9825.
>
>Best Regards,
>
>Michelle Raymond
>--------------------------------------------------------------------------
>Title
>
>Existing through Emergency: Continuity and Contingency functioning
>during emergency incidents
>
>
>Brief Description
>
>Emergency Incidents of any size or source have the capacity to disrupt
>business, government and 'life' as usual.
>
>Increasing reliance on electronic information exchange may impact the
>level of disruption. However, well managed information exchange during
>an incident may also provide business, government and other
>organizational structures means for direct involvement in mitigation
>of the incident and its aftershock. In some cases it may even enable
>specialized operational functions that can bring in alternate revenue
>and positive publicity for the participating entities.
>
>Keys to success include:
> - data access during an incident,
> - information sharing expedited by data format and vocabulary
>standards within organizational silos,
> - resource registries,
> - common model and protocol structure for information exchange and
>integration into incident response systems,
> - and other applicable Service Oriented Architecture (SOA) practices.
>
>
>Position Paper / Presentation Outline
>
>1. Emergency Management viewed as eBIZ/eGov interoperability
>leveraging and support
>2.Common protocol for information exchange
>3. Common format to communicate about resources needed / available
>during an incident
>4. Common data format and vocabulary for sectors
> 4a. Information specifically integrated into Data Exchange Language
> (example: EDXL-HAVE (Hospital AVailability Exchange)
> 4b. Sector standards specific information
>exchange via distribution wrappers
> (example: oBIX (Open Business Information eXchange))
>5. The fit of the Service Oriented Architecture (SOA) aspect of eBIZ/eGov
>
>
>Text grabbed from existing documents as a basis point
>
>1. EMTC Charter
>Across the nation, government agencies, non-governmental organizations
>and private sector emergency management offices use a wide array of
>software platforms for managing data about emergency conditions,
>resources and response activities. Most of these are stand-alone
>systems with limited capability for data sharing with other agencies
>or other levels of government.
>
>Advances in information technology have paralleled the movement toward
>more integrated approaches to emergency management. In particular, the
>emergence of service-oriented architectures has created new
>opportunities for interoperability among diverse emergency information
>systems utilizing existing industry-standard technologies. At the same
>time, other data communication facilities, such as digital television
>and radio broadcasting, are being brought to bear on the challenges of
>emergency information exchange.
>
>Application of these technologies to the emergency management domain
>requires the design and refinement of new standards for data
>structures and message-exchange processes. The purpose of this
>Technical Committee is to design, develop, and release XML-based
>standards that provide a framework for interoperability among diverse
>emergency information systems.
>
>2. EDXL-DE spec
>This Distribution Element specification describes a standard message
>distribution framework for data sharing among emergency information
>systems using the XML-based Emergency Data Exchange Language (EDXL).
>This format may be used over any data transmission system, including
>but not limited to the SOAP HTTP binding.
>
>3. EDXL-RM draft
>The primary purpose of the Resource Messaging Specification is to
>provide a set of standard formats for properly formatted XML
>emergency messages that are specifically designed for information
>payloads related to Resources required for all activities associated
>with emergency incidents. The Distribution Element may be thought of
>as a "container". It provides the information to route "payload"
>message sets (such as Alerts or Resource Messages), by including key
>routing information such as distribution type, geography, incident,
>and sender/recipient IDs
>
>4a. EDXL-HAVE draft
>HAVE is a draft XML specification that allows the communication of the
>status of a hospital, its services, and its resources. These include
>bed capacity and availability, emergency department status, available
>service coverage, and the status of a hospital's facility and
>operations.
>
>4b. oBIX draft
>oBIX is designed to provide access to the embedded software systems
>which sense and control the world around us. Historically integrating
>to these systems required custom low level protocols, often custom
>physical network interfaces. But now the rapid increase in ubiquitous
>networking and the availability of powerful microprocessors for low
>cost embedded devices is weaving these systems into the very fabric of
>the Internet. Generically the term M2M for Machine-to-Machine
>describes the transformation occurring in this space because it opens
>a new chapter in the development of the Web - machines autonomously
>communicating with each other. The oBIX specification lays the
>groundwork building this M2M Web using standard, enterprise friendly
>technologies like XML, HTTP, and URIs.
>
>The requirements and vertical problem domains for M2M systems are
>immensely broad - too broad to cover in one single specification.
>oBIX is deliberately designed as a fairly low level specification, but
>with a powerful extension mechanism based on contracts. The goal of
>oBIX is to lay the groundwork for a common object model and XML syntax
>which serves as the foundation for new specifications. It is hoped
>that a stack of specifications for vertical domains can be built upon
>oBIX as a common foundation.
>
>The following design points illustrate the
>problem space oBIX attempts to solve:
> · XML: representing M2M information in a standard XML syntax;
> The principle requirement of oBIX is to develop a common
>XML syntax for representing information from diverse M2M systems. The
>design philosophy of oBIX is based on a small, but extensible data
>model which maps to a simple fixed XML syntax. This core object model
>and it's XML syntax is simple enough to capture in it's entirety in
>one illustration provided in Chapter 4. The object model's
>extensibility allows for the definition of new abstractions through a
>concept called contracts. The majority of the oBIX specification is
>actually defined in oBIX itself through contracts.
> · Networking: transferring M2M information in XML over the network;
> Once we have a way to represent M2M information in XML,
>the next step is to provide standard mechanisms to transfer it over
>networks for publication and consumption. oBIX breaks networking into
>two pieces: an abstract request/response model and a series of
>protocol bindings which implement that model. Version 1.0 of oBIX
>defines two protocol bindings designed to leverage existing web
>service infrastructure: a HTTP REST binding and a SOAP binding.
> · Normalization: standard representations for common M2M features:
>points, histories, and alarms;
> There are a few concepts which have broad applicability
>in systems which sense and control the physical world. Version 1.0 of
>oBIX provides a normalized representation for three of these:
> · Alarming: modeling, routing, and
>acknowledgment of alarms. Alarms indicate a condition which requires
>notification of either a user or another application.
> · Histories: modeling and querying of time
>sampled point data. Typically edge devices collect a time stamped
>history of point values which can be feed into higher level
>applications for analysis;
> · Points: representing a single scalar value and
>it's status - typically these map to sensors, actuators, or
>configuration variables like a setpoint;
> · Foundation: providing a common kernel for new standards;
> The requirements and vertical problem domains for M2M
>systems are immensely broad - too broad to cover in one single
>specification. oBIX is deliberately designed as a fairly low level
>specification, but with a powerful extension mechanism based on
>contracts. The goal of oBIX is to lay the groundwork for a common
>object model and XML syntax which serves as the foundation for new
>specifications. It is hoped that a stack of specifications for
>vertical domains can be built upon oBIX as a common foundation.
>
>5. OASIS website
>Service Oriented Architecture (SOA) represents a collection of best
>practices principles and patterns related to service-aware,
>enterprise-level, distributed computing. SOA standardization efforts
>at OASIS focus on workflows, translation coordination, orchestration,
>collaboration, loose coupling, business process modeling, and other
>concepts that support agile computing.
>
>On 14 Dec 2006 20:50:26 -0000, michellearaymond@gmail.com
>