EDXL-DE White Paper

Effective and Efficient Emergency Communications? Learn about the OASIS EDXL Distribution Element[1]

David Aylward[2], Gary Ham[3], and Timothy Grapes [4] – July 6, , 2009

Executive Summary

All the key reports on 9/11, Hurricane Katrina, and similar disasters have pointed to failures and weaknesses in emergency communications and information sharing as critical and primary problems. Information that would improve response and/or make responders safer is too often not accessible. The result is loss of life and property, repeated underperformance and/or failure, and overall system inefficiencies.

Emergency organizations of all kinds could provide more informed response (and responders and the public would be safer) if they had access to, and could effectively share needed information. Given the enormous number of independent organizations, the only way to get that done is to (a) treat the diverse emergency response communities as a single, “virtual enterprise”, (b) use standards-based, open “network-centric” architectures (instead of end point focus) and (c) focus on those technical, policy, and process elements that enable all the organizations in that “eco-system” to share with each other. This approach focuses on what is needed “in the middle” to connect both new and legacy systems of tens of thousands of emergency organizations - far more easily and cheaply accomplished than traditional approaches. It lets the end points (agencies themselves) make the different decisions on information acceptance, interfaces and use.

The OASIS[5] Emergency Data eXchange Language Distribution Element (EDXL-DE) is a perfect example of this approach. It began with a requirements effort, supported by DHS that included representatives of almost all the emergency response domains to answer the question:

There are lots of different data message payloads in the emergency world and more coming. Can we introduce a common way to intelligently route them, a common envelope that all middleware systems can process, and end point systems recognize?

That practitioner working group submitted a detailed draft specification to the international XML standards body OASIS in 2004. The OASIS Emergency Management Technical Committee produced a final international standard in 2006: the EDXL-DE. This paper describes the DE in some detail. Just as importantly, it describes what is needed for the DE to properly perform its mission. The mission of the DE is intelligent routing of any standard or non-standard payload across a wide variety of Internet protocol networks, facilitating broad interoperability across all domains and professions so that systems can automatically understand and process critical information. We want to eliminate unnecessary message translation or re-keying for dissemination. So we describe the context in which the DE needs to function, and how coupled with “core services” and open standards-based, payloads, the DE allows seamless, flexible and intelligent routing.

By analogy, think of the emergency services world as tens of thousands of towns (agencies) connected by lots of different, but intersecting railway systems (networks). The DE represents a common design for train engines. Those engines can pull an infinite variety of information payloads of very different forms (flat cars, box cars, tankers).

The bottom line is that this approach provides a rapid and low-cost solution to information-sharing problems we face. With the EDXL-DE, if we can get a message to an agency IT application, in almost every case the recipients can read and make use of it.

Challenges do remain. To truly have a coherent “virtual safety enterprise” and realize its benefits, senior leadership must start thinking about the big picture eco-system of emergency communications and information technology and how to achieve interoperability within it. One critical path to be followed is focusing on the things that are needed to make the DE perform up to its capabilities. We have followed that path in this paper.

Agencies need to be connected to secure IP networks. (The gauge of the railroad tracks needs to be the same).
The Core Services to provision the DE with routing information and policies must be established and standardized. (There need to be standardized, shared software applications for recording destinations and interests in cargoes, who is allowed to open switches, what cities can receive certain cargo, etc)
Policies for access control must be developed to be registered in the core services. (The appropriate government bodies must make the rules and policies to be entered into these standardized core services)
Substantially more funding and resources must be directed to initiatives that drive cross-domain requirements for additional standards, standards-based message brokering, and development of best practices for registering organizations and rights policies in the core services, and having legacy messaging systems interact with them.
Demonstration capabilities and vendor direction is needed so the vendors will rapidly adopt standards through clear policy and direction, well-defined customer requirements, and a clear business / profit model.

But the basic data needed to support intelligent distribution can today be structured in a standard way using the EDXL-DE. This can facilitate widespread adoption across not just one network, but also a whole network of interconnected networks and applications. We strongly encourage parties working on data sharing efforts within individual and multiple emergency domains to carefully review the DE, and to adopt it for routing their payloads.

Introduction

All the key reports on 9/11, Hurricane Katrina, and similar disasters have pointed to failures and weaknesses in emergency communications and information sharing as critical and primary problems. 9-1-1 and emergency information and communications technologies remain largely stuck in the technology and mentality of the 20th Century. Information that would improve response and/or make responders safer is too often not accessible. The result is loss of life and property, repeated underperformance and/or failure, and overall system inefficiencies.

The emergency response environment requires effective communication between all elements of an extraordinarily diverse eco-system of over 100,000 independent organizations (not counting the private sector and the general public). Information needed by responders exists in a multiplicity of publicly and privately controlled locations. Two way interoperable communications need to link high level administrators, leaders at incident scenes, individual responders, and those they serve: the public citizens of the United States and the organizations to which they belong. This need for communication is not just hierarchical. Leaders need to communicate with those they lead (those systems are reasonably good), but it is often just as important for peers in one community to communicate with different communities at all levels for warning, for requesting and offering assistance, for obtaining information from public and private sources, and even just to report status. Thus communication needs form a “network”, not just a hierarchical “chain-of-command” (although command hierarchies must also be supported). As noted, these needs cross traditional organizational boundaries. Of course, police and fire need to communicate, but so do public health, public works, private organizations with either resources to offer or problems to resolve, and all sorts of individual and groups that have a stake of some sort in the world of emergency preparedness and response.

This communication cannot be solely the traditional, and still critical, voice method on which emergency response historically has been based. Data can be organized, characterized, prioritized, and repackaged for general and/or specialized use in ways that cannot be done with voice. Effective data communication is vital to reducing the volume of unproductive voice “chatter,” while increasing the quantity and quality of useful information available to those who need it. But effective data processing is not easy either. It requires knowledgeable people to build usable solutions that meet individual information needs across the wide spectrum of emergency applications. Traditionally, agencies have followed a “low-hanging fruit” approach where they have perceived an individual need, built a specialized system to meet that need, and called it good. As a result we have a lot of information systems that do their particular jobs quite well, but are walled off from other systems. They can’t handle the more general need to provide information across broader groups, much less the full spectrum of people and organizations that need at least some information from those systems. Due to the independent nature of emergency response and management organizations, disparate systems will always be in place, requiring the capability to easily share information between them - a “many to many interface” approach which supports interoperability between these independent communities and disparate systems. We need to cover the whole tree, not just assume each leaf on a branch only needs to talk to the other leaves on the same branch.

In the midst of quite justified gnashing of teeth about the weaknesses of emergency information and communications technology, there is a golden nugget of progress that needs to be understood and leveraged – fast. This is an international emergency messaging standard with a lengthy title: the OASIS Emergency Data eXchange Language (EDXL) Distribution Element (DE)[6]. This paper provides a “case for use of the EDXL-DE”, describing the problem that the DE solves, what the DE is, how it should best be used, and those additional functions that are needed so it can achieve its potential.

EDXL-Distribution Element (DE) Abstract

In simple terms, think of the DE as a common manila envelope, with a common addressing scheme (city, state, zip code, etc) and additional flexible routing options that all organizations involved in emergencies can use to send around messages and information of any kind. The common envelope and addressing allow a wide variety of middle ware, “mail handling” machines, to move these envelopes across the large number of networks owned by various organizations and agencies, to and from their legacy applications, confer appropriate security, and allow end points to recognize key characteristics about the contents. Using the DE and a couple of other software tools would provide a rapid and low-cost solution to the alert and warning and other information-sharing problems we face, moving towards overall emergency information interoperability amongst the tens of thousands of emergency response agencies. And though the DE can carry any type of payload, standard XML payloads carried by the DE move yet another step closer to broad interoperability so that systems can automatically understand and process information seamlessly.

Today there is a multiplicity of use-built, stove pipe warning and other systems (both among safety agencies, and between them and the public), and numbers are growing[7]. We need to link these legacy systems, not replace them. We need to be able to reach the public and vice versa both through social networks of all kinds, and more formally through established agencies, services and businesses. We need to connect official sources of any hazard alerting in any area to any and all systems of communication in use by the public[8]. The way to do that is with two common message standards – the OASIS Distribution Element and the OASIS Common Alerting Protocol (and shared core services[9]) – not by building new systems or stand alone products.

For other use cases which stretch beyond single domains, it will be some time before the content of messages can be standardized. But we can’t wait that long to begin sharing data in other circumstances between domains. We strongly believe that the DE can and should be used by all emergency domains to “wrap” almost any form of message payload. That way data can be delivered to any authorized organizational participant, and they can at least read the XML or use standard objects and documents, and share middleware systems. This would be a huge step forward.

The Problem

Emergency organizations of all kinds could provide more informed response (and responders would be safer) if they had access to, and could effectively share information such as video, text messages, car crash data, key personal electronic health data, resource and hospital data, building plans, extrication guides, traffic information, electronic maps, weather and hazmat data, decision support information, and other similar information and/or capabilities. A vast quantity of such information and knowledge management applications is available electronically somewhere, but usually not to the brave responders and supporting organizations and staff who need them, when they need them. From the first 9-1-1 call at the beginning of an emergency, to the patient’s going home from the hospital, and from the onset of a disaster to the communities’ recovery, we need to give all our responders (i.e. give their organizations) access to all the information they need, when and where they need it.[10] The only way to get that done is to treat the emergency communications system as a single, “virtual enterprise”, and focus on solutions that all the organizations in that “eco-system” need so they can share. The US military has faced a similar problem and designed “network-centric” architectures and solutions for it.

The current morass of emergency communications policy is not due to a lack of emphasis and resources on homeland security at the local, State and Federal levels; it results from disjointed and uncoordinated efforts funneled through the different individual safety professions, reinforcing their historical stand-alone perspectives and the technology procurement that flows from them.

Another historical pattern is that modernization efforts have focused almost exclusively on the end points (individual agencies), and/or siloed networks of endpoints of single professions (e.g. law enforcement; emergency management agencies). To move information between those end points and agencies (and from and to the private sector and the public), major Federal and state efforts need to focus on network-centric solutions – on what is needed “in the middle” to connect the legacy systems of tens of thousands of emergency organizations.

An architectural model is in place to address the interoperable, diverse, many-to-many, dynamic system we need to serve: it’s called the Internet. Indeed, that same model points to the proper role for standards and the federal government.

The OASIS EDXL Distribution Element is a very important step forward in that regard. Unfortunately, one standard can’t make a revolution. So this is a paper about the Distribution Element and its ability to address immediate interoperability issues, as well as the broader context needed to achieve its potential. By analogy, we must have a common envelope with a common address structure, but we also must have postal machines that can read and route the mail based on that information, and we need directories of zip codes and their geographies. For the DE and similar advances to fully succeed, indeed for us to make serious progress towards interoperability, the DE (or any single standard) cannot be seen in isolation. Other major policy steps focused “on the middle” are critical.

We need to reverse the traditional focus on buying new “transport” (on communications networks and devices), and instead concentrate on the “application layer”, where linking legacy systems through standards-based interoperability and information sharing is far more easily and cheaply accomplished.
In the few instances of direct Federal expenditures for software systems, there has been a dominant focus on buying specific Federal software applications and trying to convince State and local agencies to use them. Instead we need to provide network-centric tools and standards that enable the sharing of information between diverse new and legacy applications. Let the agencies select the end point software and hardware that serve their needs. The only requirement should be that they must have interfaces to the standards and shared services “in the middle.”
The very small government-enabled efforts to establish common standards across all the domains (professions) involved in emergency preparation, response and recovery[11] need to be given serious funding and priority; the handful of larger programs are domain-specific, or limited to a few domains. They need to be made ecumenical, and accelerated with resources.[12]
There is no shared “Yellow Pages” registration system for emergency organizations, enabling routing of incident information to the appropriate participants in the right geographic areas from the safety eco-system[13] (by analogy, what is the “zip code area” for notifying others of the incident). Nor are there standards supporting a federated system of these “agency locator” services (the equivalent of DNS servers for email: .com, .net, .gov etc.); therefore every sender of emergency messages needs to know and keep up to date its own list of the recipient organizations, and how to send data to them – this almost guarantees incompleteness, inaccuracy, and inefficiency.
In the same way, to ensure security there need to be, but we lack, standardized and federated organizational access control and identity management services across all the emergency response domains; and standards for them. These would record information rights policies, enabling the organizations registered in the sister locator services to know which ones are allowed to send and receive emergency information, or that they are who they assert they are in electronic communications[14]. Instead, this information resides in individual systems, or we substitute for it by having restricted access networks, thus creating silos by agency, jurisdiction or domain.
Scarce local, State and Federal funds are often being spent inefficiently on duplicative programs and functions due to the stove-pipe and balkanized approach that has been followed in governance, goals and funding, and the architecture and procurement that flow from them.[15]

Why is this? The primary reason is that emergency information and communications technology (ICT) decisions traditionally have been made at the individual agency and/or profession level. Whether it is local, State, or Federal government, there is no senior official above (and with authority over) the individual agencies and professions in charge of the big picture of emergency information and communications technology. There is no senior local[16], State or Federal agency/official responsible for overall emergency communications and information technology (much less overall operations), with the responsibility and budget to bring a coherent “virtual safety enterprise” analysis, architecture, and solutions to the problem. While some agencies have made contributions to elements that will advance this enterprise, no senior official is insisting on overall systemic outcomes and efficiencies. Instead, the officials in relevant positions are almost invariably focused on improving the functioning of single agencies (e.g. new CAD system in a 9-1-1 office), a single profession (e.g. new public health alerting system for medical personnel), or a single function (e.g. P-25 radio, or broadband radio, needs of first responders).