EDXL-DE White Paper by kMd55I68

VIEWS: 38 PAGES: 28

									    Effective and Efficient Emergency Communications?
     Learn about the OASIS EDXL Distribution Element1
           David Aylward2, Gary Ham3, 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.

The emergency response environment requires effective communication between all
elements of an extraordinarily diverse eco-system of over 100,000 independent

1
          The OASIS Emergency Date eXchange Language (EDXL) Distribution Element (DE) is an international XML
data messaging standard designed to route emergency messages of all kinds. http://xml.coverpages.org/OASIS-
Emergency-EDXL-DE-v10-os.pdf. The authors have each at various times been compensated by the Department of
Homeland Security for work on emergency response messaging standards. This paper was supported with a grant
from the Emergency Interoperability Member Section of OASIS for which we are grateful. OASIS, the Member
Section, and DHS are not responsible for any of the opinions expressed here. This paper is a living document;
comments are welcome.
2
          David Aylward is President of COMCARE Emergency Response Technology Group. He was a founder and
Director of COMCARE Emergency Response Alliance (www.comcare.org) and a former Chief Counsel and Staff
Director of the US House Subcommittee on Telecommunications, Consumer Protection and Finance. He has
worked on improving emergency response, including emergency healthcare, for more than a decade.
daylward@comcare.org.
3
         Gary Ham is a systems architect currently working with FEMA’s Disaster Management Program Office in
support of the program’s Open Platform for Emergency Networks. His is also a founding member of the OASIS
Emergency Management Technical Committee and a co-author with other committee members of the EDXL-DE
standard. gham@grandpaham.com
4
        Timothy Grapes is co-owner and Vice President of Evolution Technologies, Inc. He has worked on
emergency response issues for over 7 years supporting FEMA, and the development of NIEM and the EDXL-DE,
HAVE, RM and pending standards. He is a facilitator of the formal EDXL practitioner requirements process,
member of the Emergency Interoperability Consortium (EIC), and an OASIS Emergency Management Technical
Committee voting member. tgrapes@evotecinc.com
organizations plus the private sector and the general public. Information needed by
responders exists in a multiplicity of publicly and privately controlled locations with
independent organizations, disparate systems, and silo systems approaches. The
ability for localities, and indeed their professional agencies, to make their own
procurement decisions is not likely to change.

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

5
       OASIS is the leading international XML standards body. www.oasis-open.org.

                                                    2
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


                                             3
              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
                                             4
“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

6
          A full description of the DE and its history may be found at the OASIS website which, with praiseworthy
efforts by a group of volunteers of the Emergency Management Technical Committee, produced the final technical
standard: http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc



                                                        5
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
growing7. 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 public8. The way to do that is with two common message

7
          For example, the WARN Act has agencies establishing a one way alert capability that will use public
broadcasting infrastructure only to get to stations and cell companies, only to deliver alerts to cell phones, only up
to 90 character text messages, and only for Presidential alerts, “life threatening” emergencies, and “Amber alerts”.
Those three use cases and pathways should be components of a comprehensive alert and warning system, but that
is not the current approach.
8
          See footnote 9. All these systems need to be able to register for this purpose in an agency locator core
service; register their authority to send and receive messages about different kinds of incidents over different
                                                          6
standards – the OASIS Distribution Element and the OASIS Common Alerting Protocol
(and shared core services9) – 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

geographic areas via access control core service; and have their identities confirmed by an identity management
core service when they communicate. These are some specific capabilities that we have in mind when we talk
about things needed for the DE to achieve its potential.
9
         These are managed, standardized services shared by all emergency domains; much like the Domain
Name Service is a standardized way of addressing for the Internet. Examples include the agency locator service (a
“Yellow Pages” of emergency organizations), and federated systems for access control and identity management.
10
         A short video at www.comcare.org/video.html provides a vision of how emergency medical response
could work if enabled in this fashion. Unlike the faster progress described in this paper for public alerting and
warning, and a few other capabilities, that vision is more complex. While some parts of it can be achieved quickly,
the broader vision expressed there is probably only achievable in the medium term (3-4 years).

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

                                            8
        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 recovery11 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-system13 (by
         analogy, what is the “zip code area” for notifying others of the incident). Nor are

11
          DHS S&T practitioner EDXL requirements process and FEMA’s Disaster Management Program supported
the creation of the DE, and several other broad-based EDXL emergency message standards. The authors were
active participants in these projects; and were often compensated by DHS for their work.
12
          These include the National Information Exchange Model (NIEM) (now primarily a taxonomy based on the
Global Justice data standards effort, with a bit of homeland security recently added; some other emergency
response domains are peripherally involved), the Health Information Technology Standards Program (HITSP) for
electronic health records standards (now mostly hospitals and large health IT companies, with a bit of public
health, and a smattering of emergency response based on an emergency use case), and DHS S&T practitioner-
based EDXL standards development efforts.
13
         Several years ago, the FCC’s Network Reliability and Interoperability Council VII’s 1D Report called for
these “Facilitation Services” to be established. This paper and others now call these applications “Core Services”.

                                                         9
         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
         communications14. 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 local16, State or Federal agency/official responsible for overall emergency
14
         See footnotes 8 and 9.
15
          Aside from safety and security benefits, an extremely interesting study would compare the Total Cost of
Ownership to local, state, tribal and federal governments of the current siloed systems under the control of their
multiplicity of masters, with the TCO of a modern efficient system looking at safety as an overall “virtual
enterprise”, based on Internet Protocol where backbone networks, core services, enterprise services, and other
appropriate functions and costs are shared, while legacy and new customer premise applications are required to
communicate externally using standards.
16
          There are a handful of local jurisdictions which have now given authority over all ICT in the jurisdiction to
a Chief Technology Officer, or Chief Information Officer, see, e.g. Fairfax County, Virginia; Washington, DC.

                                                           1
                                                           0
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).



    It seems that no emergency response Chief Operations Officer or Chief Technology
Officer is developing shared requirements for an overall emergency response (or
processes that are proxies for such positions). No one is looking at the total cost of
ownership of emergency information and communications technology for the Federal
government, much less Federal, State, local and tribal (and thus finding the overall
savings that come from optimizing a much larger, shared interoperable network).
Though NIMS partially addresses the issue, no one is demanding true “all-hazards”, all
domains, cross-profession planning, design, and implementation. DHS is heavily
focused on terrorism, intelligence and law enforcement versus disasters -- and almost
not at all on daily emergencies, although many more people are affected by these day
to day incidents. It conducts little coordination with health. HHS focuses on health IT
for health professions. It pays significant attention to a broader group of participants in
pandemics, and some mass disasters, but not other emergency medicine. DOJ
generally focuses on intelligence and crime, and related criminal justice matters; DOT
does traffic information, EMS standards, and some 9-1-1 in three separate silos. Most
state and local agencies (rather than the federal government) focus on day to day
emergencies. State “interoperability committees” were formed to rationalize the
expenditure of federal emergency communications funds, but with a handful of
exceptions are focused exclusively on building new digital, narrowband police and fire
radio systems. The FCC is embroiled in a debate on creating a national wireless
broadband network for responders – with almost zero reference to other forms of
emergency communications.




                                              1
                                              1
   Agencies and program staff understandably resist taking on projects beyond their
boundaries and they have little incentive to do so. If they did, they would insist on
shared applications that would produce overall benefits.



    The appointment of new overall Federal Chief Technology and Chief Information
Officers creates an intriguing possibility of a coordinated solution, but thus far they have
had no involvement in emergency ICT. This backdrop helps show why the EDXL-DE is
such an outstanding example of what is possible when a broader perspective is taken.
Let’s now move on to explore what the DE is and what it does to deal with the problems
discussed above.



Data Interoperability Options

       The DE was created as a direct result of an analysis of the various forms of
interoperability. The requirement was for a tool to help address data communications
about “n” incident types, flowing between dynamically changing groupings of “m”
organizations, with varying levels of required security. There are several interoperability
solutions, each with is own set of strengths and weaknesses.

      Point-to-point. Point-to-point interfaces are designed to allow direct interfacing
       between systems. You must know who you are connecting with and the protocol
       for the connection. The voice equivalent to point-to-point connectivity is having a
       private telephone line between you and the other party. You pick up when you
       want them; the phone rings at the other end. This is a simple solution if the
       number of needed connections is small. It can be quite complicated and time
       consuming in a metropolitan area where the number of needed connection is
       large and the protocols for connection are often different for each connection. It
       is entirely unmanageable for larger areas.
      Hierarchy. In a hierarchical network, all communication is made up or down a
       defined tree defined something like a typical organization chart. In fact,
       hierarchically structured data networks are usually designed to mimic the
       organizational structure that employs them. They offer control at the expense of
       immediacy. Top-to-bottom or bottom-to-top communication works well enough,
       but leaf-to-leaf (bottom of one branch needing to communicate with the bottom of
       another branch) suffers from too many connections in between. This may cause
       information to be slow to arrive in an emergency, garbled by too many
       intervening connections, or even held up in the upper level control bureaucracy.
                                             1
                                             2
       Think of the challenges of a two way telephone calling tree. In data these
       challenges are often exacerbated if the connections require different protocols
       and data structures to be implemented.
      Broadcast Network –Broadcast sends data across a wide network to any
       system or application that is connected. These have the same advantages and
       disadvantages as radio. First you have to use the same data structures and
       protocols across the network, just like you have to use the correct radio
       frequency and band. Connectivity to the network gives you the power to provide
       information to everyone on the network at the same time. But, again just like
       radio, disciplined content is required or “chatter” overwhelms the valued content.
       Success requires keeping broadcasts to a minimum and content to that needed
       by the maximum number of network members. And, of course, it is one way
       only.
      Publish Subscribe – Publish subscribe networks go a long way toward reducing
       the chatter issue. Users subscribe to get information in the categories they want.
       Publishers publish information by category to all users that have subscribed. This
       technique is effective if both publishers and subscribers use consistent
       categorization schemes. Subscribers must know both the category and structure
       of information that is available and subscribers must publish using known
       categories and structures. Categorization can be multi-faceted, including things
       beyond just the base topic of the information. Adding a geographic area of
       interest to the categorization scheme is one very good example. With more than
       100,000 organizations involved in emergency response, resident on a multiplicity
       of networks, a critical problem is how to publish and how to subscribe. How does
       my agency know that you may have information that is of value to us so we will
       register to receive it? How does your publishing reach me if we have registered
       some other place for this kind of information?
      Intelligent Routing – Intelligent Routing addresses these issues by going
       beyond straight publish subscribe. It adds intelligence to the network in the form
       of “middleware.” The intelligent router or message broker must be able (directly
       or through access to other network-centric applications such as core services) to
       know both the characteristics of its potential connections (the systems and
       applications of the organizations that connect to it) and at least some of the
       characteristics of the data that passes through it from one connection to another.
       The router then uses this knowledge to ensure that connections get the
       information they want and/or need to see and do not get the information they
       should not see. “Should not see” includes both the application of security (not
       allowed to see) and relevancy (waste of time to see) criteria.


   So, which is the best solution for data interoperability? The answer is “All”. You will
hear some people claim that publish subscribe is good enough for general information
feeds. Others will correctly say we need capability including, but not limited to, general
                                             1
                                             3
information feeds. Others say that the cost involved in intelligent routing is too great
when they know where they want to send data. A direct connection is far more efficient.
Others will say that they need hierarchical control for effective management. Still others
will say that broadcast is clearly the most effective mechanism for warning in a serious
emergency that affects a large number of people. Actually, all of these people may be
correct from their particular viewpoint (and their program’s budget), but none of them is
taking an overall view, seeking to optimize a solution for all emergency response.

       A critical difference is, that if an intelligent routing system is in place, parties can
undertake any of the other forms of communication discussed above through the
application of rights management independent of the message and networks (this is
exactly what an access control core service does). The opposite is emphatically not
true. So a key focus and design objective for the DE was making sure it would help
enable intelligent routing.

The Specific Problem the DE Solves
       Over the last 10 years, we have seen the development of a large number of
different taxonomies and message payloads, as various parts of the emergency eco-
system realized the value of data sharing. Unfortunately these were not developed in a
common, coordinated way. Thus, in the Justice community we have seen a focus on
common taxonomy17, with a much looser standard for grouping those into
communications packages or Information Exchange Packet Documentations (IEPDs).
The health industry has very different taxonomies18 and forms of data sharing
documents.19 Intelligent transportation system leaders developed the first set of
emergency data message structures (versus documents).20 Some of us helped 9-1-1
organizations, telematics and emergency medical leaders create the Vehicular
17
         A major long term effort by the entire Justice community resulted in the Global Justice XML Data Model
and Dictionary. This was converted essentially wholesale into the National Information Exchange Model (NIEM)
when a prescient leader in the DHS CIO’s office tried to find a basis for developing a common taxonomy with other
professions. Unfortunately, the project has never been given the resources and high level support it needs, so it
has not achieved its ecumenical promise. We hope that will change.
18
         For example, SNO-MED for hospitals, NEMSIS for EMS.
19
         For example, Health Level 7 which is founded on “document communication” versus data sharing.
20
          This was a trailblazing effort. These are recorded as the IEEE 1512 message family. Despite efforts by the
leaders, only transportation experts participated so there was never buy-in from other domains. The ITS people
later agreed to use the NIEM taxonomy in their message structures.

                                                         1
                                                         4
Emergency Dataset (VEDS) for crash data from companies like OnStar.21 Last but not
least, many of us associated with emergency management participated in developing,
testing, and standardizing the OASIS Common Alerting Protocol (CAP) for public
warnings22, as well as other emergency response messaging standards.

       These have all been valuable efforts. They all serve the purposes for which they
were developed: often one or a handful of emergency domains’ specific needs. But for
those trying to develop intelligent routing systems to move information among the
multiplicity of networks and applications, these messages/documents have one thing in
common: they all look entirely different to middle ware systems. They are envelopes of
different sizes, with different addressing systems, or no addressing system. In short,
they are a disaster for interoperability. In looking at “the middle”, how to share between
all domains, the requirement for a common standard for packages or payloads was
defined.

        The challenge is to be able to assemble data as information that can be used on
all forms of networks without restructuring, so that networks themselves can be
connected. In other words, we need to be able to move an envelope around without
opening it, and translating it into a new language to move to a second or third network.
For example, we need to be able to send a message about a potential threat point-to-
point from an undercover field operative to a review site for confirmation, then
hierarchically to its appropriate approval point for dissemination to the public, and then
by broadcast to either key agencies or the general public, without having to
electronically unpack the content of the message, or hand transcribe (or rekey) the
original data. All those networks and their middle ware need to be able to read and
function with the distribution mechanism (the “envelope”).

       That will get the information to the endpoints. Then the end points have to be
able to read the content to make the network interoperability worthwhile. Here again a
common XML structured envelope allows customer systems to sort out those messages
in which they have interest and translate those in their internal application language,
while ignoring others. Moreover, XML allows displaying the content of any message
even if the end system cannot act on it. This is true because XML is composed of text
with labels in a format that every major Internet browser application can display.
Additionally, most browsers can also display XML using an additional file called a XML

21
       See www.comcare.org/VEDS
22
       See http://www.oasis-open.org/specs/index.php#cap

                                                  1
                                                  5
style sheet (XSLT). This means that, if the sender of an XML document includes an
accompanying XSLT document, the receiver of the XML document can view its content
in a browser in the format desired by the sender with virtually no programming on the
receiver’s side.

     The bottom line is that if we can overcome the middleware issues and get a
message to an agency IT application, in almost every case they can read it.



The EDXL-Distribution Element (DE)
        So where did the DE come from? To meet these challenges, the Department of
Homeland Security’s Disaster Management Program (at the time under FEMA, but later
transitioned to DHS S&T) funded in 2004 a several month process whereby experts
from all the affected emergency response domains cooperatively developed the
requirements and a draft detailed specification for the Emergency Data eXchange
Language Distribution Element23. It defined a standard XML “container” for emergency
information that facilitates the transfer of that information using any data network and
any network topology. The Emergency Interoperability Consortium (EIC) approved the
draft and formally submitted it to the OASIS Emergency Management Technical
Committee. After lengthy consideration, rounds of international public comment, and
significant improvements, the OASIS EDXL DE became an international standard in
2006.

       The Distribution Element is a standard XML structure (with a formally recognized
XML Schema for validation) that has two basic purposes. It wraps information so that all
kinds of content can be encapsulated and sent using routing mechanisms that may not
understand what is in the message, and it characterizes that content in order to make
routing more flexible and effective.

DE Content
      We will talk content first. Just about any kind of information can be contained in
a DE message. It was specifically designed to contain other XML messages (such as
OASIS CAP, EDXL Resource, EDXL Hospital Availability, future EDXL messages; IEEE


23
         DM chose Art Botterell, the driving force behind the creation of the Common Alerting Protocol, and
COMCARE, with its broad-base membership of the emergency professions and industry, to be the technical and
organization leads respectively for this project.

                                                      1
                                                      6
1512; or VEDS), but it is just as effective as a distribution wrapper for other standards
and non-standard content. Content from HealthLevel7, IEPDs developed from GJXDM
or NIEM, and any other standard XML data structure are all legitimate content for
routing with a DE wrapper and use in a DE-compatible network or application. Indeed,
the official version of the Department of Health and Human Services’ electronic health
records interoperability project public in the Federal Register earlier this year. says
exactly this. The Health Information Technology Standards Panel (HITSP) electronic
health record interoperability specification for use of electronic health records in
emergency medical response24 endorses using the DE as the wrapper for other HITSP-
recommended constructs. Moreover, standard non-XML content (like graphics, any file
with a defined mime type (e.g., tiff, doc, jpeg) also has a place as content. Finally, even
non-standard content can be accommodated.

        The natural reaction to the claim in the paragraph above is “HUH?” In fact, the
secret is conceptually very simple. The actual content of an EDXL DE-wrapped
message is a set of content objects that can either be XML objects or non-XML objects.
Each of these objects must be described and characterized in a DE standard way, but
may actually contain essentially anything, because the content itself is encapsulated
away from any actual distribution related processing activity. The separate descriptive
information is used by members (nodes) of a DE-enabled network to determine if they
understand the content well enough to process it. The characterization information is
used by a DE-enabled network to aid in distribution. The content itself just goes along
for the ride until it reaches a node on the network that both can and wishes to process it.

DE Characterization
So let’s talk about the characterization information in the DE and its purpose. There are
several XML tags in the DE that are specifically used to characterize the message.
Some (not all) of these include:

        Distribution Status – Covers the use of the message in a sense. Values include
         Actual, Exercise, Test, and System (for determining message action ability).


24
          HITSP Interoperability Specification Number 04 is a detailed description of how to share all or part of
electronic health records with the full range of the emergency response community (e.g. 9-1-1, EOCs, EMS, public
health, not just hospitals) during emergency medical events. It endorses use of the OASIS EDXL DE, EDXL HAVE,
and OASIS CAP. It discusses using the DE as the wrapper for other HITSP “constructs”.
http://www.hitsp.org/InteroperabilitySet_Details.aspx?MasterIS=true&InteroperabilityId=51&PrefixAlpha=1&APre
fix=IS&PrefixNumeric=04

                                                       1
                                                       7
        Distribution Type – Describes the use of the content in a functional sense. Values
         include Report, Update, Cancel, Request, Response, Dispatch, Ack
         (acknowledge), Error, and some specialized types relating to sensor information
         content.
        Combined confidentiality – Describes the highest level of security that needs to
         be applied to the content. This is the greatest level that applies to any content
         item wrapped in the DE or to an even higher level if the combination warrants it.
        Language – The primary language of the content using the ISO standard
         abbreviations for language (e.g., en-US for U. S. English).
        Sender ID – An identifier for the actual person, organization or system (e.g.,
         sensor) responsible for creating the message. This ID may or may not be made
         subject to security concerns related to access control and identity management,
         such as confirming that the sending party is authorized to be on the network and
         to send the message (access control), identity validation, and non-repudiation.
         The more secure the network, the more these identity management rules need to
         be employed.
        Sender role – A description of organizational role/function of the individual
         responsible for creating and sending the content. This is who it is from in a
         functional sense, and is also critical to access control, which needs to be role-
         based.
        Recipient Role – A description or the organizational role/function for which the
         content of the mission may be of interest. This describes who, from a functional
         sense, should see the content. This means that Senders do not need to know
         recipients or their addresses. Note that here can be multiple Recipient Roles
         defined for one DE instance.
        Keyword – A further categorization of content that is user (or community)
         definable. This is the categorization that an intelligent router might use to sort
         information into different RSS feeds or route to different networks that concern
         specific kinds of emergency information. Note that there can be multiple
         Keywords defined for one DE instance. The most obvious of these and a very
         useful addition as an Optional Field25 is “Incident Type”, so Senders need not
         know all the roles of parties which might be interested in receiving the
         information.
        Target Area – The geographic area of interest for recipients of the message; this
         can be a point or a polygon. Extensions could and should provide room to
         accommodate richer GIS detail that is called for in core services requirements
         (e.g. jurisdiction area for the functional role; mutual aid area for the role; general
         interest area for the role).


25
        Indeed, we believe it will become mandatory in future versions of the DE. A number of us have
developed a project to develop managed lists of incident names and roles. See pages 23 and 24 below.

                                                      1
                                                      8
        Explicit Address – A definition of the type and value associated with a directed
         recipient for a particular message. Used for direct routing, regardless of other
         criteria.


Of course the DE also has one or many Content Objects (e.g. an EDXL Resource
Message, a NIEM IEPD, and/or a JPEG file representing a related photograph). The
Content Object is the container element for specific messages. It must either contain
XML Content or non-XML content. Additional elements (metadata) used for specific
distribution of the <contentObject> payload or hints for processing the payload are also
present in the Content Object such as sender roles, recipient roles, and more keywords.
All of this is used to wrap each content item as described above.

Avoiding the “Code Wars”
        On the surface, the DE, as described above, looks like a good distribution
wrapper, if everyone uses the same categorization schemes to describe incident types,
roles, keywords, and similar information structures. We strongly encourage efforts in
that direction26, but those do not exist today, and for some time there will continue to be
differences. Therefore, the creators of the DE chose an approach that accommodated
different schemes. They said, “Let’s stay out of the code wars by accepting any valid
code, so long as there is an authoritative source for the code that can be referenced,
and the sender references it in the message.” So, virtually anywhere where a code
might be put into the DE, they put in a two-part data structure consisting of a source for
the code list (called “valueListUrn”) and an actual value (called “value”) that must be
available on the referenced list. This allows the DE to provide a standard structure for
characterization as a wrapper for content, but use established code lists from other
sources as the content for that characterization. In the DE this techniques is used
specifically for all keyword and role structures. For example, an allowable role structure
might look like this:

         <recipientRole>

                 <valueListUrn> org.comcare.epad.orgroles<valueListUrn>

                 <value>9-1-1 center<value>


26
          For example, FEMA “resource typing” efforts and initial work on a project to develop common incident
names across all US emergency domains, starting with the lists of each profession, adopting those whenever
possible, and focusing on the overlaps.

                                                       1
                                                       9
       <recipientRole>

      What the above entry tells you is that there is a list or organizational role that is
maintained under the Uniform Resource Name = “org.comcare.epad.orgroles” that has
a member of the list equal to “9-1-1 center.”

       This sort of structure has the advantage of identifying what list is being used and
what the value being used in a message is based upon. It is not as efficient as having
one standard list for the entire US and/or international emergency eco-system world. In
contrast, however it is achievable now. When organizations use the DE for
characterization, they can continue to use the lexicons with which they are familiar.
Over time, we will either develop official all-emergency domain “Managed Lists” (e.g. of
US incident types) and/or certain code lists will be used more often than others. The DE
developers hope that, in this way, the market of actual use will create a “de facto” set of
code lists that are used most often in DE compatible networks as well as a set of
standard interfaces to access those code lists for reference and validation purposes.

Using the DE and Related Applications in Different Network
Environments

A DE is, at its simplest level, a plain piece of XML. As such it does not care how it is
transported or where. It is just a text file. Its value, however, is that it can contain
structured data that allows intelligent distribution across a wide variety of networks. The
sections below describe how the DE works in each type of network and how an
intelligent distribution network can be use DE data to simulate each of the other network
types.

Directed Distribution
None of the specific fields of a DE need to be used to achieve the directed distribution
of a file. The sender chooses the node on the network to which they wish to send a
message and either sends the message to that node (synchronous communication), or
places the message on a server to be retrieved by that node (asynchronous
communication). Even in this simple network, however, the DE has value. Any kind of
content can be sent because a separate service interface at the middleware level does
not have to be built for each content type. Additionally, receivers can use the DE
characteristics to determine if they understand the content, or wish to process it further
upon receipt. As an analogy, think of using the DE characteristics as a sort of spam
filter on the receiving end.
                                             2
                                             0
Interestingly, a directed distribution network is not limited to directed distribution alone,
so long as it has connectivity to other networks. For example, if one node on a directed
distribution network actually represents a transmission point to another network, then
that other network can be the chosen target of a directed distribution. The chosen
target then could use the full power of the DE to redistribute the message according to
its distribution paradigm (e.g., the target could be a broadcast point like NOAA Weather
Radio or perhaps a separate publish/subscribe network).

Intelligent distribution networks simulate directed distribution by using the Explicit
Addresses tag in the DE to allow senders to choose specific target nodes for receiving a
message (and in intelligent networks the receivers can specify in the agency locator
core service whether they want data pushed to them, or the server from which they
want to pull data).

Hierarchical Distribution
Hierarchies are like directed distribution except that distribution points are limited by
hierarchical rules. Communication is directed either up the hierarchical chain or down
that chain, and there is no “jumping” of the chain (e.g., intermediate nodes in the
hierarchy cannot be bypassed). Leaf-to-leaf distribution is also restricted in that such
communication must be submitted up the chain until it reaches a mutual superior in the
hierarchy before it can be directed back down to its target. Even in such rigidity, the DE
has value as a container of multiple content types. Further, the network can define
organizational roles for its member nodes (used in Sender Role and Recipient Role)
that can be associated with hierarchical roles, making updates to hierarchical
distribution rules less onerous.

With intelligent distribution, this process could be monitored and controlled with a role-
connected rules engine (i.e. the access control core service to which we repeatedly
refer) to enforce appropriate hierarchical distribution paths. The saving in maintenance
costs and increased responsiveness could be significant when compared to hard-coded
or hard-wired connectivity controls.

Another important argument for using an intelligent distribution network for hierarchical
uses is that hierarchies can be dynamic; they may need to be changed almost in real
time. For example, the role of “incident commander”, the subsidiary organizational
functions, and their authorities are relatively fixed. However, their identities and thus
their organizations can change quickly during an incident (a fire becomes a crime
event).


                                              2
                                              1
Broadcast Distribution
Broadcast distribution means sending the message (or making it available
asynchronously) to every possible reception node that can connect. Broadcast is very
efficient in terms of time. It can be very inefficient in terms of wasteful data processing
and/or review time for receiving systems. Properly written DE content can be used by
receiving systems to filter out what is not desired, or cannot be effectively processed, by
them. In fact, receiving systems do not even have to process the entire stream of XML.
They just need to read enough of the incoming DE XML stream to make a decision
about the value of the content. Here is where the DE begins to shine. “It’s a fire in the
next city; our agency is not involved.” Receiving systems know what they can process
and can look for it. They can also be programmed to recognize priority content and
content that can be processed later. The various information XML tags, when used
properly, provide enough parsing information that a system can afford to open itself up
to receiving broadcast data because it can apply filters early enough in the reception
process that it is never choked with garbage (from its viewpoint). Only usable and
desired information gets through.

Intelligent distribution takes this one step further. Because the receiving node has
characteristics of its own that are known to the routing middleware, broadcasts can be
tailored to be sent only to organizations that may need that information – without the
sender having to know this information. This is the information that organizations that
desire to receive information enter into an agency locator core service registry, and
keep up to date themselves. Receivers can still apply filtering, but will have to do so
less often. Additionally, network traffic can be reduced significantly.

Publish/Subscribe Distribution
In a Publish/Subscribe Environment, the receiving system is allowed to place some of
its filtering capability at the sending end of the connection, or at a server “in the middle”.
By establishing pre-defined interests based on DE tag structure and content as
subscriptions, a receiver can ask for particular content to be sent or, conversely, ask
that a particular content not be sent. The appropriate data could be registered to
accomplish: “Send all hazmat messages in or adjoining Columbia County to this URI.”
Nodes that accept subscriptions then publish messages using directed distribution to
their subscribers when DE’s with matching tags are received or created at the
publishing node. As above, receivers still have the ability to apply filters, but will not
have to do it often. There are many individual publish/subscribe opportunities available
on the web today. Most, however, speak to a specific information feed rather than a
targeted type of information regardless of feed. The DE offers the latter. Moreover, the

                                              2
                                              2
user can choose level of granularity of the information target based on any combination
of DE tag structure. This is real power.

One of the limitations of publish/subscribe at the sender location, and even in various
servers, is that organizations are forced to register (and keep up to date) a multiplicity of
registrations. This guarantees a level of inaccuracy and incompleteness.

Once again, intelligent routing mitigates this problem. For intelligent routers, the routing
software actually does not have to be in the same system as the registry. Indeed,
decoupling them promotes open architecture, with the registry acting as a service to any
number of authorized routers. In fact, there may actually be more than one subscription
registry where systems might register interest in particular kinds of messages or
content27. An intelligent router would then query multiple registry services using DE
constructs found in a candidate message. It would then route the message to all
interested parties. Authorization of those parties would occur by a similar querying of
access control services.

Intelligent Routing
The highest value that can be achieved using the DE is actual implementation of
intelligent routing. By standardizing the structure for emergency message identification
and characterization, the DE allows the decoupling of services for identification of
information types, identification of organization types, provision of access control and
identity management, provision of security services, provision of routing rules
management, and other “core services”. The routing service employs other services as
needed to support both direct distribution and network broadcast as appropriate.

For directed distribution, an intelligent router ensures that explicit addresses are used to
known (non-reputable) network nodes, subject to routing and security rules that may be
in place to support hierarchical structures, and the registered desire of some nodes not
to be targeted.

For broadcast, needed information is sent to all who want it (registered subscriptions for
such incidents in the affected area) and those may want it (based on organizational
characteristics), subject to routing and security rules that may be in place to support
hierarchical structures and organizational restrictions based on a standardized query to



27
         The agency locator core services described herein assume multiple renditions of a standardized
organizational registry, with standardized queries – like the DNS system in the internet.

                                                       2
                                                       3
an access control core service, a cross reference of organizational characteristics and
security requirements.

The specific rules for how intelligent distribution is accomplished will vary by
implementation. Because the access control rules and agency registry are decoupled
from intelligent routers, different levels of government in different areas can set different
access and distribution rules for different incident types. This is critical because there is
no single system of permissions that applies to all forms of alerts and warnings, much
less all emergency messaging and information sharing.28

But the basic data needed to support intelligent distribution can now be structured in a
standard way using the DE. This can facilitate widespread adoption across not just one
network, but also a whole network of interconnected networks and applications.

Challenges
Managed Code List Availability and Consistent Usage
Interoperable, effective routing of emergency messages (and the efficiency of the DE) is
enhanced by having agreement among emergency domains on common names for
incident types. The DE can route any emergency message payload based on key
factors, such as geography and incident type. The data standard explicitly calls for a
common “Managed List” of incident types for this purpose – but no such list has been
developed (e.g. “Tidal wave” or “tsunami”? “Leak” or “exposure”? “Flu” or “pandemic”?
“Crash” or “accident”?) The interoperability of a wide variety of message payloads (from
public warnings, to nuclear sensor information, to hospital resource information, to car
crash data) would be significantly improved if such a Managed List of common incident
names were produced.

Similarly, rights to send and receive such messages are determined by incident type,
geography and role. Role is based on level of government, entity type and function.
The “incident commander”, “responding EMS”, “jurisdictional 9-1-1” and so on have
particular rights to send and receive information. These rights can and do vary by
jurisdiction, but if we are going to have interoperability (particularly supported by
federated access control), we need a standardization of what we call “level of

28
          The federal IPAWS warning project will eventually run into this challenge, which heretofore has been
avoided by limiting the sources of warnings, and the types of warning, and positing that an “aggregator” approach
will solve whatever problems remain, i.e. designate some entity to solve the problem. However, centralized
solutions cannot scale and only address the needs of the specific cases they are charged to solve.

                                                        2
                                                        4
government” (local, State, tribal, Federal, private, NGO, etc), “entity type” (law
enforcement, EMS, urgent care, 9-1-1, etc) and the “roles” they have in responding to
emergencies of all kinds.

The authors and others have proposed an effort to get leaders of the key emergency
response domains to reach a common agreement on what to name incidents and roles.
An initial draft was developed with the support of the Emergency Interoperability
Consortium. Once completed, we intend to turn over the Managed Lists over to an
appropriate repository29. In an ideal world, this activity would be sponsored by the
Federal Government. Unfortunately, there is currently far too little Federal support for
emergency data standards for sharing information across the full range of emergency
response community.

We have developed a cooperative project to address this need. Each participating
organization will be asked to appoint one or more experts from its own membership who
can speak for it, and (depending on the specific group) to reach outside its own
membership to fairly represent the listed field. This will include assembling any incident
naming from the “universal core” terms for NIEM that have been produced, and
guidance from the National Incident Management System (NIMS) office to ensure
conceptual alignment with NIMS. In addition, the groups will review incident names in
the standards work of hospitals and public health (HL7, DEEDS, PHIN, HITSP), EMS
(NEMSIS), transportation (IEEE 1512 and ITS), public safety (NFPA, ATIS, NENA,
APCO and ESIF), government (HHS, FEMA, NIMS, DNDO, DOJ, DOC), and the
commercial world (OASIS, ANSI, TIA, and others).

Core Services
The DE was designed with network-centric provisioning data bases in mind for key
information about recipients and rights. On receipt of a DE message, an intelligent
message broker queries the core services and provisions the specific fields in the DE
with the obtained information. The initial ones should be:

            o Agency locator/GIS-based registry of organizations involved in
              emergencies30
29
           The National Information Exchange Model (NIEM), a pilot project of DHS and DOJ, is an obvious candidate
for this repository role.
30
          COMCARE has undertaken years of functional and technical requirements development resulting in a
detailed design for the agency locator registry, called “EPAD”, and detailed technical and design requirements for
the companion access control/identity management core service. www.comcare.org/epad

                                                         2
                                                         5
            o Access control/identity rights management and related security services31

With core services, the initiators of DE wrapped messages need not know what
organizations want to receive that information, or are allowed to. Similarly the recipients
need not independently question the right of the sender to transmit it. All parties are
provided with the security of identity management. And agencies only have to register
this key routing and rights information once, and then keep it current in one location.
Multiple standardized versions of these core services can exist, and query each other
for agency information in another geographical area or other grouping.

Detailed requirements and design for these core services exist today, but they are not
yet in the marketplace. Key shared core services need to be deployed and
standardized32 that will allow efficient interoperability over the entire safety enterprise,
helping connect networks and applications into what an FCC report called an
“internetwork”33:

Governance and Policy Development
The emergency response community does not now have policies and rules to govern an
interoperable, integrated, modern system of information sharing -- in other words the
policies and rules to record in the access control core services. Some rights rules exist
in some forms (e.g. what official may send out a public health alert for the county, and
who may receive one). Core services are simply software tools. They need to be
populated by decisions of appropriate government authorities at each level of
government. For example, while only the President or his designee will have the right to
send out a national alert message about a threat to life, a Mayor has that right for his or
her jurisdiction, his or her city. Some messages may have mandatory distribution with
some parties, many will be permissive.




31
         See www.comcare.org/core_services.html.
32
         The Open GeoSpatial Consortium has developed a detailed plan to do exactly this: in an open, inclusive
process develop standards for the content and querying of the two core services described here. It awaits a
leading company to build and test the first alpha versions of core services meeting the developed requirements.
33
         See FCC Network Reliability and Interoperability Council VII, Report of Group 1d, 2005, www.nric.org.

                                                        2
                                                        6
The Federal government needs to jump start this process by providing funding to
develop best practices for registering organizations and rights policies34 in the core
services, and having legacy messaging systems interact with them.

Vendor Adoption
Our experience is that vendors will rapidly adopt standards when policy is clear, the
requirement to do so from their customers is clear as well, and a clear business / profit
model is both well understood and is at least competitive with current lucrative models
developing one-off solutions, applications and interfaces that must be re-done again
and again . Most IT vendors to the various parts of the emergency space have not yet
heard about the DE from the Federal government, much less State and local
governments. If they have, many regard it as something relevant only to a subset of
the eco-system (“emergency management” or “DHS grantees”). Nor do they have a
clear message from those Federal, State and local government purchasers that they (a)
need to build to the DE and (b) that doing so is in fact part of an open, standards
based, and network-centric architecture direction. Even DHS grant guidance is
permissive rather than mandatory.

Probably most important, most government officials with some responsibility for this
area are not approaching it from the overall “virtual enterprise” or “safety eco-system”
perspective that the DE was designed to address. If you only focus on law enforcement
data communications with other law enforcement agencies, for example, the benefits of
the DE and supporting core services are reduced, though still significant.

Showing People How It Works
It is neither practical nor desirable to have a single message brokering system. The
value of standards is that a multiplicity of middleware and end point systems can be
supported, encouraging innovation and cost competition. But to get the ball rolling and
provide a friendly test bed, the government could provide and host middleware for
intelligent message brokering, security, and use of (and auditing of compliance with)
agency location, access control and other core services.35 The new version of the DHS
Disaster Management OPEN system could be used for this purpose, but should be


34
          Core services do not formulate rights policies; they simply provide a software application in which to
record those policies and implement them efficiently. The rules themselves are made by the appropriate body for
the incident type, geographic area, and level of government.
35
        FEMA’s OPEN message broker is currently being redesigned.

                                                       2
                                                       7
designed to take advantage of external and standardized core services (as modules or
from third parties), rather than trying to be “the single application in the center.”

This could then demonstrate the use of the DE with CAP, the new EDXL message standards for
resources and hospital status, and other payloads such as HITSP constructs and NIEM IEPDs.
This could also provide an opportunity for a test bed to solve problems and determine options to
meet requirements for current and future programs such as IPAWS, CMAS, EAS etc.

Conclusion
We believe the EDXL-DE is a model cross emergency domain solution. We believe its
use will provide a rapid and low-cost solution to information-sharing problems we face,
primarily by creating a “common middle ware language”. Properly implemented, it can
cut through the Gordian Knot of agency and public alert and warnings.

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.

Challenges do remain. The DE cannot solve interoperability on its own. To truly have a
coherent “virtual safety enterprise” and realize its safety and economic benefits, we
need senior leadership which will look at the overall emergency ICT picture for the first
time, and how to achieve interoperability within it. One critical task is focusing on the
things that are needed to make the DE perform up to its capabilities. We have sought
to lay these items out in this paper.

We welcome comments and suggestions.



David Aylward                               Gary Ham                             Tim Grapes

daylward@comcare.org                 gham@grandpaham.com          tgrapes@evotecinc.com




                                               2
                                               8

								
To top