-
BCG Response to NYSOEM Draft Sandy AAR February 24, 2014
Executive Summary
The Sandy After Action Report draft includes 6 major
inaccuracies and falsehoods about the DLAN system that need to be
specifically addressed. 1. The report says that DLAN crashed during
Sandy operations. DLAN never crashed during Sandy operations. While
there were some other issues with NYSOEM IT infrastructure that
were beyond the control of BCG and may have temporarily prevented
users from accessing the system for brief time periods, DLAN never
crashed during Sandy. 2. The report says that NYS is the only state
to use DLAN and OEM is the only major emergency management agency
at any level in NY that uses DLAN. DLAN is used in 6 states and 9
counties within in NY, as well as numerous other locations across
the US and Canada. DLAN is in use by the State of Vermont, the
State of MN, the US territory of Guam, the regions of Halton and
Ontario Canada, and inumerous counties and cities in states
throughout the country from New York to California. Additionally,
within NYS DLAN is utilized by Chautauqua, Cattaraugus, Erie,
Niagara, Ontario, Rockland, Westchester, Livingston, and Orange
counties, as well as the Seneca Nation of Indians and the NYS
National Guard in Albany. It is also important to point out that
many, many more counties are trained in DLAN and have accounts on
other county systems. 3. The report says that DLAN is incompatible
with other systems. DLAN is fully NIMS-compliant and can
communicate with any other system that complies with federal
interoperability standards. DLAN is the ONLY Crisis Incident
Management System to have passed every NIMS-STEP evaluation test
for interoperability and NIMS-compliance. DLAN supports the CAP
& EDXL data interoperability standards promoted by FEMA/DHS in
addition to email and web services data exchange. BCG cannot speak
to other systems ability to share information interoperability, but
we have always made the effort to meet all interoperability
standards. 4. The report says that DLAN needs substantial on-site
contractor support. DLAN does not need substantial on-site
contractor support. NYSOEM requested, and BCG provided around the
clock on-site support during Sandy, the vast majority of which was
not DLAN related. As noted in the report, NYSOEM is understaffed,
and many key personnel were shifted to the ROC in NYC leaving the
EOC even more shorthanded. BCG personnel have extensive state-wide
activation experience and were able to help fill some of the gaps,
providing just in-time training and assistance for out-of-state
people both for DLAN and non DLAN-related areas. 5. The report says
that DLAN does not include a modern asset tracking system. DLAN has
a fully functional asset tracking and resources module and various
iterations of these modules have been recommended to NYSOEM before,
during, and after Sandy. Over the past several years, BCG has
worked with NYSOEM staff to identify, design, and cost out the
1
-
ideal asset management system that could be used by their
logistics staff. BCG provided NYSOEM with multiple cost-effective
proposals, in advance of Sandy, that were not executed by the
agency. 6. The report says that DLAN is insufficiently understood.
BCG employees provided just-in-time training for those unfamiliar
with NYSOEM procedures and policies as well as with DLAN. DLAN is
an extremely intuitive and easy-to-use system. The basic
methodology for using DLAN can be explained in fifteen minutes or
less. DLAN has been designed and configured to tightly integrate
into NYSOEM operations and thus we do see value in including policy
and procedure training along with DLAN software training - the two
go hand-in-hand. As seen in this short synopsis, the Sandy After
Action Report draft included several inaccuracies and falsehoods
about BCG and our DLAN product. BCG wishes the authors of the
report had provided BCG with a prior opportunity to address how
DLAN performed during Sandy and particularly gotten feedback from
our personnel who, as stated previously, were an active part of
NYSOEMs response to Sandy. The lack of inclusion of any feedback
from BCG in this report, the many mistruths about the DLAN product,
and the final conclusion that DLAN should be replaced as NYS
incident management solution bring the intentions of the author
into question. The following pages address in detail the many false
accusations laid against DLAN in this report and it is our hope
that this information will give a more accurate assessment of
NYSEOMs response to Sandy and both DLANs use and BCGs participation
in this response.
2
-
Full Response
As the vendor of the DLAN Crisis Incident Management System, BCG
takes exception to many of the libelous and inaccurate assertions
issued in the Sandy After Action Report draft. Having not been
afforded the opportunity to participate in the AAR interviews to
correct misconceptions or provide what we feel would have been
important information, we will address the reports inaccuracies
below. Should any party be interested in discussing the issues with
us, we would be happy to do so. Report Assertion 1: DLAN, the
emergency management support software used by OEM to collect and
fulfill resource requests, is insufficiently understood by many
staff, requires substantial on-site contractor support, and is
incompatible with systems used by other jurisdictions and agencies
(including, prominently, New York City, Suffolk and Nassau
Counties). Response 1: DLAN does not require substantial on-site
contractor support. While it is true that NYSOEM requested, and BCG
provided, around the clock on-site support for the first several
weeks of the Sandy response, the vast majority of the support
provided was not DLAN-related. After years of working closely with
NYSOEM, BCG staff has an in-depth understanding of their operating
policies and procedures. As noted in the report, NYSOEM is
understaffed and BCG personnel were able to fill some of the gaps
and provide services in a number of non DLAN-related areas. These
included conducting daily orientations and trainings of EMAC
support teams, general IT support and problem solving, and aiding
in building out the IT infrastructure in the NYC ROC. Appendix A
provides a list of the activities performed by BCG staff during
Sandy. Just-in-time training on DLAN was also provided, as would be
expected with any software system utilized by mutual-aid personnel
unfamiliar with both the software and organizational operations.
BCG is proud of the services and support we provided NYS during
Sandy and cannot stress strongly enough that our provided support
went far-and-beyond what level of support was required for DLAN.
Regarding the charge that DLAN is incompatible with systems used by
other jurisdictions, again we take exception. DLAN is the ONLY
Crisis Incident Management System to have passed every NIMS-STEP
evaluation test for interoperability and NIMS-compliance (see
Appendix B for a summary of FEMAs report). DLAN supports the CAP
& EDXL data interoperability standards promoted by FEMA/DHS in
addition to email and web services data exchange. BCG will not
comment on the ability or willingness of other systems to share
information interoperably, but will assert our ability and
willingness to do so. We should also point out that for several
years, BCG has been working with Regional Logistics Program on a
pilot project to share information, specifically resource
information, with other systems in use throughout the northeast.
DLAN has always been at the forefront of this information exchange
effort. See Appendix C for more information on the IEM
interoperability effort. While it is true that NYC, Suffolk and
Nassau Counties utilize systems other than DLAN, many
3
-
other counties do utilize DLAN systems. These include
Chautauqua, Cattaraugus, Erie, Niagara County, Ontario, Rockland,
Westchester, Livingston, and Orange, as well as the Seneca Nation
of Indians. DLAN is also utilized by the NYS Department of Military
and Naval Affairs as well as our cross-border Canadian partners in
the Ontario and Halton regions of Canada. Additionally, since DLAN
is a web-based solution, sold on a as a single-site license with no
per-user charges, should NYSOEM opt to provide logins to a
particular user or county, they will be easily able to access the
system and the data within.
4
-
Report Assertion 2: The most frequent source of frustration
expressed by those who have used DLAN on a regular basis is that
personnel from other agencies as well as county emergency
management agencies have not been adequately trained to use the
system. Response 2: As with any software system, some amount of
training is required. While DLAN does provide integrated help,
training videos, and quick reference guides, much of the required
training by NYSOEM users is policy and procedure based. DLAN has
been designed and configured to tightly integrate into NYSOEM
operations and thus we do see value in including policy and
procedure training along with DLAN software training - the two go
hand-in-hand. Ultimately, it is up to NYSOEM to determine if they
want to provide training to county emergency management agencies
and open up use of the system to them. BCG has, and continues to
stand ready to provide any requested training, including
just-in-time training during EOC activations (as we did for
out-of-state EMAC mutual-aid personnel during Sandy). It should be
noted that BCG conducted our own internal after action review of
Sandy, and one of our recommendations going forward is that NYSOEM
better utilize video and web-based training. For example, a
just-in-time video training module could be produced so that when
out-of-state mutual-aid EMAC personnel arrive in the EOC, they can
be provided with a computer where they can watch an orientation and
training video. This will significantly reduce the burden on
personnel required to conduct this necessary real-time training
during a large event. This training can also be made available, via
the Internet, to county emergency management agencies as well as
NYS state agency users.
5
-
Report Assertion 3: Although the State has invested
substantially over the past decade in making DLAN the electronic
backbone for OEM incident management, it is widely viewed by
emergency managers at the local level (as well as by other State
agencies) as cumbersome, inefficient, and inflexible. In addition,
other jurisdictions in New York have invested in other technologies
that are unable to communication with DLAN. As a consequence, many
officials across the State view DLAN as an impediment to effective
incident management. Criticisms of DLAN were heard at every level
of government and centered around problems of usability and
compatibility. Specific objections include:
Preparing a mission request form/ticket is time consuming and
non-intuitive; Since DLAN is felt to be too hard to use, it is not
used on a daily basis by most OEM
staff nor by local-level responders, which means most personnel
are not familiar with it operation;
Tracking the status of specific entered requests is difficult,
making management and planning for those resources and assignments
challenging;
DLAN does not readily allow users to generate custom reports -
the DLAN contractor at the EOC must develop these for users;
DLAN in not compatible with WebEOC and eTeam, the systems in use
in most counties and major cities in the State, including New York
City, which means data must be entered twice and that the databases
downstate and in Albany cannot speak to each other.
Additional complaints speak to gaps between what DLAN provides
and what is needed to support logistics and procurement,
particularly during a crisis. DLAN was never designed to be a
resource management tool, but has the capability to do so with
customization. However, unless the state and local jurisdictions
are using the same system, or have the ability to interface with
each others systems, resource management will continue to be an
issue. Response 3: The fact that DLAN was designed with NIMS
interoperability requirements in mind has been previously addressed
and will not be revisited here. As for the claim that entering a
ticket is time consuming, this is partially true. However this is
by design to force users to enter all the data necessary for
personnel to fulfill a resource request upfront instead of having
partial data entered and then having to waste time later trying to
find the needed information. This includes contact information as
well as specific information about the resource being requested.
While DLAN can be configured to allow for rapid and minimal data
entry on a ticket, in the end, this approach will end up costing
time instead of saving it. NYSOEM staff very deliberately designed
and configured the DLAN ticket entry system so that all pertinent
information necessary to fulfill a resource request is gathered.
When considering how to configure the DLAN ticket entry system, a
detailed survey was distributed to lead agency partners and county
emergency managers based on real world use case scenarios. NYSOEM
consulted with their lead agencies and counties around the state on
these use cases to develop
6
-
and review the request forms to ensure the information being
requested would allow for a more accurate and timely deployment of
resources especially in life safety situations. This also allowed
for more pre planning activities to be tied into the day to day use
of the system. This may best be illustrated by way of example.
Consider the case where a county requires a generator to operate a
hospital. It is simply not enough to enter a ticket that states
that Hospital X needs a generator. Additional information is
critical to fulfilling this order. For example, what size generator
is required, what type of fuel is available for the generator or
does NYSOEM need to provide fuel for the generator as well, are
there resources on site to off load the generator and wire it in or
does NYSOEM need to provide personnel as well, and many other
critical information points. To aid in collecting this information,
resource-specific templates have been implemented in DLAN so that
when someone designates a ticket as a Request for a generator, they
are presented with the list of specific questions pertinent to a
generator request which are required to be answered before a
generator can be deployed (see Attachment D). Yes, this requires
the person making the request to obtain this information, but there
is really no other way to fulfill such a request without gathering
the necessary information. While this does add to the length it
takes to fill out a ticket in DLAN, it ultimately eliminates a lot
of back and forth and can expedite resource deployment if the
proper information is provided up front. Frankly, much of this
information can and should be gathered during pre-planning so that
precious time need not be wasted doing so during a response. IF
NYSOEM wants BCG to remove these item-specific data collection
forms from DLAN, we would be happy to do so. Yes, in the end it
will speed up ticket entry, but you will also have a fraction of
the information necessary to deploy resources and will increase the
manpower and time required to ultimately collect this information
in the end. This is a pay-me-now or pay-me-later proposition. BCG
has proven to be very responsive to the needs, requests, and
suggestions of our customers over the years. In fact, the system in
place at NYSOEM today is the result of years worth of use, ideas,
suggestions, and improvements. BCG truly values and listens to our
customers. The generic comment that DLAN is too hard to use
typically is leveraged by people unfamiliar with and untrained in
the use of the system. If specific areas of the system are
considered too hard to use, we invite individuals to tell us
exactly what areas and provide suggestions to make the system
easier to use. We are always open to ideas and suggestions to
improve the product. But, general statements without specific
context and suggestions for improvement cannot be addressed.
Regarding the statement that tracking of requests is difficult, we
disagree on several fronts. First, every resource request in the
system is given a unique ID number. It is very easy to recall a
specific resource request by ID number so that the ticket can be
opened and reviewed. Additionally, search tools allow users to
rapidly locate a ticket based upon virtually any piece of
information entered on the ticket should they not recall the ID
number. Finally, each ticket is provided a color-coded status so
that, at a glance, users can see the status of a ticket.
7
-
We should also point out that DLAN provides some additional
tools for tracking and reporting on resource deployment. NYSOEM has
thus far opted to not utilize these resource tracking tools, but
they are available to them on their system. In terms of reporting,
the assertion that DLAN does not readily allow users to generate
custom reports , or what some other systems refer to as boards
and/or inboxes is false. DLAN has an easy-to-use custom report
generator that is available for use by any user. Just because users
are unaware of or untrained in the use of such a tool does not mean
that the tool doesnt exist. Additionally, the assertion that the
DLAN contractor at the EOC must develop these for users is also
blatantly false. During Sandy, BCG staff did take on the
responsibility of generating hourly reports for review by senior
management, but we did so because NYSOEM staffing was short. While
staff could easily have generated these reports, they frankly were
so overwhelmed with other duties that BCG staff stepped in to help.
While we previously talked about interoperability, it is probably
worth directly addressing again the assertion that DLAN in not
compatible with WebEOC and eTeam, the systems in use in most
counties and major cities in the State, including New York City
This is false in two counts. As previously mentioned, DLAN has the
technical ability to communicate and share information with these
other systems should people desire to use the interoperability
features. Also more counties in NYS utilize DLAN than WebEOC and
E-Team combined. It might be worth pointing out how the State of
Minnesota addressed similar concerns. In MN, the state, as well as
many counties, utilize DLAN; but a few counties utilize Knowledge
Center. MN approached BCG and asked if we could work with Knowledge
Center to exchange information. Since Knowledge Center didnt
support the FEMA/DHS IPAWS system for data exchange, BCG developed
a custom web service to integrate with Knowledge Centers
proprietary communications system. Today, both DLAN and Knowledge
Center share information between systems in MN. The point being
made here is that the issue of data sharing is not one of
technology, but of will and policy. Now we need to address the
issue of resource management, logistics, and procurement. While
DLAN does have an asset/resource module, it is currently not
utilized by NYSOEM. NYSOEM currently utilizes a standalone
non-web-based product called TC-MAX for assets management. Over the
past several years, BCG has worked with NYSOEM staff to identify,
design, and cost out the ideal asset management system that could
be used by their logistics staff. They envisioned a
state-of-the-art web-based system that utilizes bar-coding, mobile
hand-held devices, and GPS location tracking devices as the
ultimate solution. The proposed BCG approach was to take DLANs
existing resource module (which has 80% of the desired
functionality), identify any gaps from the ideal system, and make
necessary changes to DLAN to furnish the ultimate solution. BCG
provided NYSOEM with multiple cost-effective proposals, in advance
of Sandy, that never gained any traction within the agency.
Specifically, the following proposals were provided to NYSOEM:
8
-
Date Proposal Number 01/06/2009 Q1913 [Web-Based Interoperable
Logistics Management System] 10/16/2012 Q2390 [Resource Module]
10/16/2012 Q2392 [Advanced Resource Integrations] 10/16/2012 Q2393
[Ticket Manager / Resource Integration]
9
-
Report Assertion 4: DLAN crashed during Sandy operations (though
other incident management software packages used in other
jurisdictions also crashed under the workload) requiring contractor
assistance to reboot. Some feel that being forced to have DLAN
contractors in the EOC to support the software reflects the
limitations of the product, is expensive, and constitutes a
misuse/waste of limited floor space. Finally, observers felt that
EOC staff was engaged in working with the DLAN system to the
exclusion of communicating with other emergency operations center
personnel. This compromised their ability to share information
(this is, to be fair, another criticism that has been leveled
against other software packages). Response 4: The assertion that
DLAN crashed during Sandy is false. While there were some other
issues with NYSOEM IT infrastructure that may have temporarily
prevented users from accessing the system for brief time periods,
DLAN never crashed during Sandy. It is important to understand that
DLAN, like other web applications, relies upon other supporting
technologies. For example, if the Internet to your home goes out
and you cannot reach cnn.com, you should not assume that CNN is
broken and blame CNN. Similar issues occurred during Sandy and I
will outline the details below: During the day shift of 10/29/12,
BCG detected a slowdown in Internet performance that was unrelated
to the DLAN application. No other DLAN users noticed this slowdown,
but BCG staff detected it because we had both on-site and off-site
personnel performing continuing system monitoring. We immediately
spoke with support personnel from NYSOEM IT who stated that they
were aware of a DHSES network related bandwidth issue on their end
and were looking into it. On 10/30/12 during the day shift, we were
advised by NYSOEM IT that the wireless network was moved to another
Internet pipe and everything seemed faster for external users.
However, later that day at around 4:50 PM DLAN could not be
accessed externally. DLAN continued to function internally at the
EOC and for any users connected via a VPN connection. External user
outside the DHSES network could not reach DLAN, DHSES email, DHSES
Sharepoint servers, and other DHSES systems. This clearly was a
bandwidth-related issue related to DHSES network and not a DLAN
issue. BCG again spoke with NYSOEM IT who informed us that the
whole NYSOEM Internet was failing and that they were looking into
the issue. Other NYSOEM web sites could also not be accessed
because of this Internet issue. Again, we must point out that DLAN
did not crash, but may have been inaccessible to certain users
because of the Internet bandwidth issue. Initially, it was believed
that there was a failure in some external equipment on the AT&T
network that served NYSOEM. However, the ultimate issue was
detected by NYSOEM IT and was related to a saturation of the NYSOEM
network by Google. Apparently, upon executive orders, a KML data
feed tied to other DHSES systems unrelated to DLAN was provided to
Google so that they could provide mapping data to their Google Maps
product. Unfortunately, this had the untoward effect of saturating
the NYSOEM network with data requests thereby blocking or
preventing other traffic from passing. NYSOEM IT
10
-
immediately disabled this feed to Google and normal network
operations resumed immediately. Another issue that occurred during
Sandy that affected access to DLAN happened on 10/31/2012 during
the day shift. Due to the large number of additional personnel
operating out of the Albany facility, the network almost ran out of
IP addresses. In order to resolve this, NYSOEM IT released some of
the IP addresses they had in reserve but in doing so this caused
some issues with the wireless network. Some users in the Albany EOC
lost wireless connectivity and thus access to DLAN. While most
users were not affected, to the ones who were, it appeared as if
DLAN crashed, but it had not. Simply renewing the IP addresses for
the affected individuals restored their network connectivity and
access to DLAN. On 11/01/2012, the entire NYSOEM network had a
brief failure (cause not known to us) which again affected peoples
ability to access DLAN. But again, this was not a DLAN failure. At
10:15 AM on 11/01/2012, NYSOEM IT needed to failover one of their
SQL databases. During the process of failing over this database,
the failover process knocked out the SQL cluster upon which the
DLAN database resides. Again for a brief time, users were unable to
access DLAN, but this was not a failure of DLAN. The final event
that impacted DLAN accessibility during Sandy occurred on 11/8/12
during the day shift. NYSOEM IT conducted a planned outage of their
Storage Area Network (SAN) in order to replace a failed controller
card. The maintenance interval ran from 12:15 to 1:30 PM. Because
the DLAN database, like most other NYSOEM data stores, resides on
the Piller SAN, DLAN was briefly inaccessible during this outage.
Again, DLAN inaccessibility was not the result of a failure of
DLAN.
11
-
Report Assertion 5: It is not an indictment of DLAN to note that
only one other state uses the software, nor that OEM is the only
major emergency management agency at any level in New York that
employs it. Nor is it necessarily a criticism to observe that many
urgent or high level requests were pushed through not using DLAN,
and that the forms for many such tickets were completed after the
fact. It is important, however, to recognize that the perception
another example of the agencys dysfunction. The system has few
supporters and many detractors, does not play well with others, and
does not seem to do anything better than other, more widely
accepted, competing systems. Response 5: The authors of the AAR
inaccurately state that DLAN is used by only one other state and
that OEM is the only major emergency management agency at any level
in New York to employ DLAN. This is incorrect, and one can only
assume written to dimunitize DLAN as a product. DLAN is in use by
the State of Vermont, the State of MN, in the US territory of Guam,
in the regions of Halton and Ontario Canada, and in numerous
counties and cities in states throughout the country from New York
to California. Additionally, within NYS DLAN is utilized by
numerous counties (as outlined previously in this document)
including but not limited to the large counties of Erie and
Westchester. Also, when FEMA evaluated systems for use within their
organization, DLAN rated as excellent overall with a rating of
outstanding for past performance based upon customer interviews
(see Attachment E). Regarding the statement that DLAN does not seem
to do anything better than other, more widely accepted, competing
systems, we cannot disagree more strongly. We are intimately
familiar with competing systems, and feel strongly that DLAN is
unique in the way information is managed in a workflow-based
manner. In fact, there is an exhaustive list of features too
numerous to fully mention here that are unique to DLAN and are not
a part of any other incident management system available on the
market including (just to mention a few) full IPAWS-OPEN
integration, integration with NY-Alert, support for FEMA Project
Worksheet finance tracking, and unified communications tools for
monitoring third party information feeds. We are confident that
DLAN does things much better than competing systems, and constantly
hear from users of competing systems that they wish they could
change to DLAN because their current system doesnt do anything for
them but they cant change because they already invested heavily in
another system. We encourage you, the reader, to carefully evaluate
and compare DLAN to competing systems. Talk to users of other
systems and see how their system performed in a large event. After
conducting an exhaustive, fair comparison, we are confident that
you will appreciate the capabilities, features and flexibility that
DLAN offers. DLAN does have many supporters, within NYSOEM, within
NYS counties, and throughout organizations nationally.
Unfortunately, it appears as if the authors of this report either
ignored DLAN supporters or specifically sought out DLAN detractors.
One can only question the authors motivations.
12
-
Report Assertion 6: A modern asset tracking system tied to DLAN
(or some other incident management support software package) and to
the States procurement system, would streamline the acquisition and
delivery of requested resource to parties that need them, help
assure positive control during the operation, and facilitate
recovery and return of rented, purchased and borrowed items.
Response 6: We agree with this assessment. In fact, as stated
previously, we have advocated for and proposed such a system to
NYSOEM on previous occasions. In fact, during the response to
Sandy, BCG provided a proposal to NYSOEM to procure up to 10,000
GPS AVL slap-and-track asset tags. Date Proposal Number 11/05/2012
Q2400 [DLAN Ticket #102860] BCG went as far as to bringing our
asset tracking logistics expert in from Texas into the ROC in New
York City to help facilitate this effort. Our proposal, had it been
accepted and acted upon, would have allowed us to tag up to 10,000
assets with a combination of satellite and cellular-network tracked
AVL devices. Each asset would have been trackable on a map and
complete location reporting would have been possible. BCG could
have initiated the field-deployment of these devices within 24
hours of approval at a very reasonable cost. Unfortunately, this
proposal was not acted upon and NYSOEM failed to adequately track
deployed resources. We strongly feel that going forward, a robust
asset tracking system should be tied to DLAN. Report Assertion 7:
The technology backbone of the State EOC is solid, but undercut by
an incident management software system that is not accepted by the
local communities that need to use it and a physical plant that is
not conducive to efficient operations. Response 7: Again, we take
exception to the statement that DLAN is not accepted by the local
communities. In fact, DLAN is used successfully and
enthusiastically used by numerous counties throughout NYS. Many of
the comments we have heard from counties is that while they want to
utilize DLAN, they have been prohibited from doing so by NYSOEM.
Additionally, the DLAN customer base in NYS continues to grow with
several counties currently interested in adding DLAN to their
incident management tool set.
13
-
Report Assertion 8: DLAN should be replaced. A competitive
process should select a replacement which is more flexible, better
integrated with other systems in the State, and fully capable of
providing the functionality and flexibility needed in an evolving
emergency. Response 8: While we welcome an open, honest,
head-to-head, feature-to-feature comparison between DLAN and other
systems, we disagree with the assertion that DLAN should be
replaced. We strongly believe that the complete feature set, custom
integrations, flexibility, and rich capabilities of DLAN are not
understood by the authors of this report, by the numerous untrained
individuals who responded to Sandy, or by NYSOEM executive
management. NYSOEM Warning Point, Operations, and Planning staff
are well training in the advanced capabilities that DLAN provides
and their staff depends on them to meet the daily requirements of
their job. The authors even go as far as to admit this by stating
that it should be noted that OEM personnel familiar with and
trained in the use of DLAN feel it is an effective tool for
supporting EOC operations. As we have shown in our response, the
draft AAR report is riddled with inaccuracies, misinformation, and
mistruths. We contend that not enough weight was given to DLAN
supporters during the assembly of this draft report, and that
ignorance regarding DLANs configuration and capabilities has led to
many of the inaccuracies of this report. As stated at the beginning
of this document, we must also reiterate that BCG was never
interviewed during the report creation process. Had BCG been given
the opportunity to address these inaccuracies, perhaps this report
would have more accurately reflected reality.
14
-
APPENDIX A Services that BCG provided to NYSOEM during Hurricane
Sandy Activation
At the request of NYSOEM, BCG was called upon to provide on-site
staffing to NYSOEM for the response to Hurricane Sandy both
pre-landfall and post-landfall. NYS initially requested 24/7
support for the Albany EOC, but ultimately requested additional
support for the establishment of a New York City Regional
Operations Center. Per the request of NYSOEM, BCG provided cost
proposals for the requested staffing levels, and upon execution of
a work order, BCG deployed the requested personnel to the EOC. At
the end of each period of performance, NYS assessed their need to
have BCG continue their support of the operation, and BCG again
provided a quotation to NYS based upon the level of support
requested. NYS then would issue another work order and BCG would
maintain or deploy personnel as required. This process repeated
until such time that NYSOEM determined that support was no longer
required. During the activation, BCG personnel provided numerous
services both related to and not related directly to BCG product
offerings. BCG personnel were willing to provide any type of
support requested by NYSOEM. Below is a sampling of the
activities/services provided by BCG:
Provided 24/7 support to the Albany EOC Served as liaison to
incoming EMAC teams and provided:
Just-in-time training on DisasterLAN Training on NYSOEM
operating procedures, policy and workflow Orientation to EOC
facilities and introduction to personnel Creation of user accounts
and configuration of required security settings BCG typically BCG
typically ran one large group training and 20-25 small training
sessions each shift. Provided DLAN and other job duty training
to NYS agency personnel as the rotated in-
and-out of the EOC Built training videos and quick reference
sheets to help supplement NYSOEM workflow
and DLAN training Just-in-time web and over the phone training
for NYSOEM regional staff deployed to
affected counties Created DLAN user accounts, roles, and
security permissions as needed to support new
accounts, changing user requirements, and changes in EOC
operations throughout the incident
Handled password resets Created custom reports (hourly, shift,
and daily) to support the dynamic needs of the
NYSOEM EOC, NYSOEM ROC, NYSOEM Regions, Nassau County, Suffolk
County, State Agencies, and other affected counties. Some sample
reports included:
Neglected ticket reports Custom reports based upon type of
resource request Custom reports based upon agency
15
-
Summary activity reports Graphs and charts Outstanding resource
requests in various stages of processing by NYSOEM
Provided custom data exportation and importation Supported
NYSOEM IT with server equipment troubleshooting and advanced
NYSOEM
process support to overcome NYSOEM technology issues as needed.
Activities included:
Supporting NYSOEM Operations when the Oracle Pillar SAN failed
on 11/8/2012 Supporting NYSOEM Operations with paper copies of
tickets and backed up
reports when the Oracle Pillar SAN failed on 11/23/2012
Troubleshooting of the NYSOEM wireless network which became
overloaded by
users several times during the incident Troubleshooting of the
NYSOEM external network which became overloaded by
external user bandwidth requirements several times during the
incident Troubleshooting EOC user issues on NYSOEM networks,
computers, and
equipment several times during the incident Troubleshooting of
DMNAs DLAN server hardware hosted in NYSOEMs
datacenter several times during the incident Assisting with
backups of DMNAs and NYSOEMs DLAN servers several times
during the incident Supported NY-Alert with server equipment
troubleshooting and advanced NY-Alert
process support to overcome NY-Alert technology issues as
needed. Activities included: Spent a large amount of time
monitoring and troubleshooting issues that
occurred under heavy system load, which eventually led to the
determination that NY-Alert did not have enough Email Servers.
Assisted Kevin Ross in configuring 4 new email servers.
Created a Software Load Balancer in NY-Alert that could more
evenly distribute emails between all of our SMTP Servers during
heavy load
Created new custom features for NY-Alert to support Hurricane
Sandy activities including:
Added the ability to dynamically add new Email Servers without
interrupting service
Added a special managed re-try handler for a particular types of
issues NY-Alert encountered with NWSs Weather Alert Feeds
Added the ability for notifiers to specify that a particular
Group Notification use link-based security only: i.e. anyone with
the link to the notification can view it.
Added a cache control mechanism to the public alert map to avoid
issues where, under heavy load, old data would remain cached too
long instead of updating when it should
Provided custom NY-Alert importation and configuration to
support a transfer for NYC alerting system to NY-Alert
Routine hourly backups of tickets for NYSOEM Operations Routine
hourly backups of status board slides for NYSOEM Planning
Configuration changes to DLAN modules to support NYSOEM
Branches
16
-
Research and custom integration with Gentrifi AVL and WDT
weather data feeds to support NYSOEM EOC operations
Custom data cleanup to fully fill out tickets for people who
entered incomplete data Provided requested support to New York City
Regional Operations Center. Activities
included: Staffed the New York City Regional Operations Center
to provide training on
NYSOEM workflow, NYSOEM policies and procedures, and resource
requesting on DLAN for State Police, Public Service Commission, and
military personnel coming to support the operation
Coordinated with NYS GIS (Frank Winters) to support GIS data
sharing needs throughout the incident
Created graphical maps of proposed floor plan layouts Worked
with NYSOEM staff to physically wire the Regional Operations Center
in NYC.
Activities included: Running wires Installing Wireless Access
Points Assisted in loading and unloading equipment and cargo for
the ROC to help
support NYSOEM Operations and DHSES IT Installing printers
Distributing and configuring laptop computers Assisted in loading
and unloading equipment and cargo for the ROC to help
support NYSOEM Operations and DHSES IT Researched advanced
system-to-system replication options to help support
DHSES IT Troubleshooting of network, Internet, and bandwidth
issues to help support
DHSES IT
17
-
18
-
APPENDIX B
NIMS-Step Evaluation Summary Report
19
-
20
-
21
-
22
-
23
-
APPENDIX C
Regional Logistics Program
24
-
DISASTER LOGISTICS
NY NJ CT PA
REGIONAL LOGISTICS PROGRAM
Sept 2012
Regional Data Interoperability & Resource Management
Assessment Paper
-
DISASTER LOGISTICS
Regional Data Interoperability & Resource Management
Assessment Paper
-
This document is intended to provide structure to disaster
logistics operations and is not prescriptive or comprehensive. The
actions described in this document will not necessarily be
completed during every event, nor is every activity that may be
required described in this plan. Federal, state, and local agency
personnel will use judgment and discretion to determine the most
appropriate actions at the time of the event.
-
Table of Contents
2
3
4
6
Connecticut 12
New Jersey 14New York 14Pennsylvania 15State-to-State (EMAC)
16Federal 16
Existing Standards-Based Information Sharing Capabilities 17
20
22
25
Appendix A: NIMS-Supporting Technology Evaluation Project (STEP)
28
Appendix B: Additional Research 29Appendix C: Additional
Resources 32
Glossary 33
Acronyms 35Bibliography 37Planning Team List 39Contact
Information 40
Preface
Using this Document
Overview
Overview of Existing Systems
Information Sharing Mechanisms
Information Sharing Capabilities
Adopting EDXL-RM
Implementing EDXL-RM in the Region
Establishing Regional Operational
Coordination
Appendices
References
-
2Established in 2008, the Regional Catastrophic Preparedness
Grant Program (RCPGP) is a groundbreaking Department of Homeland
Security initiative to encourage collaborative emergency planning
in Americas largest regions. The New York-New
Jersey-Connecticut-Pennsylvania (NY-NJ-CT-PA) Region includes four
states, 30 counties, hundreds of cities, towns and villages, and
spans three FEMA regions. With a population of 22,000,000 people,
this region is home to nearly 1 in every 14 Americans.
The Regional Resource Management Solution (RRMS) project was
executed by the NY-NJ-CT-PA RCPGP Regional Logistics Program, under
the guidance, supervision and oversight of the Regional
Catastrophic Planning Team (RCPT), and with contributions from the
multi-jurisdictional Regional Information Management Solution
(RIMS) Planning Team. The document is focused on jurisdictions in
the NY-NJ-CT-PA RCPGP Project Site (hereafter, the Region);
however, any agency or jurisdiction is welcome to use this
information in any capacity in which it may be found useful.
Preface
-
usIng ThIs DoCuMenT | CoNFIDENTIAL. FoR oFFICIAL USE oNLY 3
using this Document
This Assessment Paper summarizes the objectives and presents the
conclusions and findings of the Regional Resource Management
Solution (RRMS) initiative.
Find project goals, objectives, and status.
Find an overview of existing technology systems in the
Region.
Review current mechanisms for information sharing in the
Region.
Learn about eDXL-RM and its potential as a data interoperability
solution.
The RRMS Regional Data Interoperability and Resource Management
Assessment Paper is part of a comprehensive suite of disaster
logistics documents created by the NY-NJ-CT-PA Regional Logistics
Program. The entire suite of documents, including a strategic
CoNoPS, operational plans, field operations guides, assessment
papers and toolkits, can be found at
http://www.EmergencyLogistics.org. Together, these documents create
the framework for a Universal Logistics Standard, providing
guidance and tools that allow emergency managers and logisticians
to prepare and implement a robust and effective disaster logistics
capability.
4 6
12
20
-
oveRvIew | CoNFIDENTIAL. FoR oFFICIAL USE oNLY4
Goal
Objectives
This document is designed to help logisticians develop plans to
improve data-sharing capabilities in their incident management
systems.
The National Preparedness Goal, published by the United States
Department of Homeland Security (DHS) in September 20111, stresses
the importance of operational coordination and interoperable data
communications between federal, state and local first responders.
It emphasizes maintaining a core capability for operational
communications to ensure the capacity for timely communications in
support of... operations by any and all means available, among and
between affected communities in the impact area and all response
forces. This assessment paper explores technology solutions that
support the National Preparedness Goal and allow jurisdictions to
maintain operational coordination and operational
communications.
Define a regional path forward to seamlessly connect local,
state and federal technology systems and automate how information
is received, shared and tracked as resources are requested and
deployed during disaster response.
1 Provide an overview of the existing technology systems used in
the Region.
2 Assess how information is currently shared between existing
technology systems
3 Identify data standards that enable jurisdictions to share
resource request and tracking information.
4 Evaluate potential middleware and other solutions that
integrate with the Regions current systems, seamlessly connecting
multiple levels of government and enhancing interoperable
communications while allowing jurisdictions to keep their existing
technology systems.
5 Evaluate potential solutions to improve the visibility of
critical assets, resources, supplies and equipment that are
deployed after a disaster.
1 Crosswalk of Target Capabilities to Core Capabilities. FEMA .
Access on May 16, 2012 www.fema.gov/pdf/prepared/crosswalk.pdf
overview
-
oveRvIew | CoNFIDENTIAL. FoR oFFICIAL USE oNLY 5
To date project accomplishments include: Convened the Regional
Information Management Solution (RIMS) Planning Team, comprised of
55 members representing 27 jurisdictions and agencies in New York,
New Jersey, Connecticut, Pennsylvania and beyond. The Planning Team
played a critical role in developing the strategy for improving
regional interoperability to support resource management.
Contacted 30 counties and 4 states to gather information on the
technology systems used by each jurisdiction in the Region.
Generated consensus among Planning Team members to recommend an
open, published data standard for interoperable data-sharing on any
current or future technology projects.
Compiled information on both challenges and best practices for
regional interoperability and resource management.
Identified baseline capabilities that all technology systems
must have in order to support interoperable data sharing.
Identified two federally-developed, no-cost options to link the
Regions technology systems.
The RIMS Planning Team remains an active working group that
seeks to further the objectives of the RRMS initiative. A
discussion of possible solutions and next steps is provided at the
end of this paper.
Project Status
-
6 oveRvIew oF eXIsTIng sysTeMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
existing Technology
within the Region
The first objective of the Regional Resource Management Solution
(RRMS) is to provide an overview of the existing technology systems
used in the Region, which are known as Incident Management Systems
(IMS). This section provides an overview of how each IMS in use in
the Region currently supports resource management and information
sharing.
In order to effectively manage resources a IMS user must be able
to: order and acquire resources Mobilize resources Track, inventory
and report resources Facilitate resource reimbursement
DisasterLAN, developed by Buffalo Computer Graphics E Team,
developed by NC4 KnowledgeCenter, developed by KnowledgeCenter Inc.
WebEoC, developed by ESi
overview of existing systems
Disaster LAn
Version 8.0.5
Version 7.5.0
e Team
Version 9.5
Version 9.02
Version 6.x
Version 3.x
Knowledge Center
Version 3.9.2
web eoC
Version 7.4.0.4
Evaluating IMSs for implementation
nJPA
CT
ny
County Agency Systems
State Agency Systems
-
7DisasterLAN DisasterLAN2, the IMS used by the New York State
Division of Homeland Security and Emergency Management (NYS DHSES)
and several county emergency management agencies within New York
State, was created by Buffalo Computer Graphics (BCG) in 2001. At
the request of NYS DHSES it has been significantly upgraded and
modified to closely resemble the agencys paper-based processes.
DisasterLAN is a web-based system that is built on an SQL
server. The software is customizable, and sold as a per-site
license. Because it is web-based, anyone with proper security
privileges and a web browser can access it. It can be deployed on a
dedicated or shared server or can be hosted virtually at
DisasterLANs data center. DisasterLAN recommends all site
installations be updated regularly to ensure that the most current
version of its software is always deployed for its users; however,
all fielded systems remain interoperable regardless of version. The
most recent version, DisasterLAN version 8.0.5, added a web-based
graphic interface that has been enhanced for mobile-web browsers.
Version 8.0.5 also has been upgraded to conform with IPAWS 3.0
interoperability, and is capable of casting messages via the
Commercial Mobile Alert System (CMAS).
DisasterLAN supports resource management through three main
modules: Call Center:3 A flexible data entry system that is
optimized for EoC information management requirements and can be
used to manage NIMS typed resources and track the full lifecycle of
a resource request, including its fulfillment and deployment.
Preplanning:4 A tool that can be used to manage information on
suppliers and stockpiles. Resources can be matched to call center
tickets requesting or donating resources.
Interoperable Messaging:5 A tool that can be used to send and
receive standards-compliant messages, while allowing access to
information (such as resource tickets, etc.) in a template-driven
interface.
DisasterLAN is the only IMS in use within the Region that has
been evaluated by the National Incident Management System
Supporting Technology Evaluation Program (NIMS-STEP), and is
therefore the only system out of the four to be certified as NIMS
compliant in Emergency Data Exchange Language (EDXL) and Common
Alert Protocol (CAP) messaging standards.6 Find more information on
the NIMS-STEP in Appendix A.
2 Reviewed by Tim Masterson, DisasterLAN software Manager, BCG.
June 22, 20123 Buffalo Computer Graphics. DisasterLAN Call Center
Ticket Manager. Buffalo Computer Graphics.
Accessed on 16 May 2012 from
http://www.buffalocomputergraphics.com/documents/DLAN%20Call%20Center%20Slick.pdf
4 Buffalo Computer Graphics. DisasterLAN Preplanning Module.
Buffalo Computer Graphics. Accessed on 16 May 2012 from
http://www.buffalocomputergraphics.com/documents/DLAN%20Preplanning%20Slick.pdf
5 Buffalo Computer Graphics. DisasterLAN Interoperable Messaging
Module. Accessed on 16 May 2012 from
http://www.buffalocomputergraphics.com/documents/interoperable-messaging.pdf
6 Results from each evaluation may be accessed at www.rkb.us
(keyword STEP). Accessed June 2012.
oveRvIew oF eXIsTIng sysTeMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
overview of existing systems
Disaster LAn
Version 8.0.5
Version 7.5.0
e Team
Version 9.5
Version 9.02
Version 6.x
Version 3.x
Knowledge Center
Version 3.9.2
web eoC
Version 7.4.0.4
Evaluating IMSs for implementation
-
8E Team
Jurisdictions Using DisasterLAN Version
New York State Division of Homeland Security and Emergency
Management (NYS DHSES)
Version 8.0.57
Westchester County office of Emergency Management Version
7.5.08
orange County Division of Emergency Management Version 7.5.0
Rockland County Department of Emergency Management Version
8.0.59
NC4s E Team, a IMS used by New Jersey and multiple agencies
throughout New York State, provides users with interactive views on
incident summaries, response operations, resource requests and
deployments.10 E Team can be accessed using most web browsers and
the system is server agnostic, meaning that it can be run on
oracle, SQL, or other servers. System access and authentication is
controlled by a role-based data-sharing and security model that can
be integrated with any existing Active Directory installation.
Managing E Teams back-end database requires no knowledge of
database programming languages; data can be filtered and displayed
via E Teams Web Services architecture. Although E Team is
considered an off-the-shelf incident management solution, its Web
Services architecture makes it fully customizable and easy to
integrate with existing plans and processes.11
E Team supports resource management through two separate
reporting tools: Critical Assets: A tool that allows an agency to
maintain an inventory of assets and resources, and tracks their
availability, location and characteristics.
Resource Requests: A tool that tracks separate resource requests
using different status notations, such as Delivered, En Route, or
Sourcing.
7 Interview with Tim Masterson, DisasterLAN Software Manager,
BCG. 22 June, 2012. 8 Westchester and orange counties plan to
upgrade to version 8.0.5 by Fall 2012 as per Tim Masterson,
DisasterLAN Software Manager, BCG. June 2012. Confirmed by
Patrick Cerra, Buffalo computer Graphics, July 2012.
9 Interview with Tim Masterson, DisasterLAN Software Manager,
BCG. 22 June 2012. 10 E Team: Functionality. NC4. Accessed from
http://www.NC4.us/ETeam.php on 5 June 2012.11 Interview with Eric
Kant, Interoperability Architect, NC4. 19 June 2012.
oveRvIew oF eXIsTIng sysTeMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
-
9Jurisdictions Using E Team Version
New Jersey State Police, office of Emergency Management Version
9.512
All county-level emergency management agencies in New Jersey
Version 9.513
New York City office of Emergency Management (county-level
emergency management duties in Bronx, Kings, New York, Queens and
Richmond counties)
Version 9.514
Dutchess County Department of Emergency Response Version
6.x15
Suffolk County Department of Fire, Rescue and Emergency
Services
Version 3.x16
Nassau County office of Emergency Management Version 9.0217
12 Interview with Tom Rafferty, Emergency Management Section of
the New Jersey State Police. 31 May 2012. The New Jersey State
Police oEM is currently in the process of upgrading their E Team
IMS to Version 9; the upgrade should be complete by summer
2012.
13 Interview with Tom Rafferty, Emergency Management Section of
the New Jersey State Police. 31 May 2012.
14 Interview with Mark Frankel, New York City office of
Emergency. June 2012. NYC oEM is currently in the process of
upgrading their E Team IMS to Version 9.5.
15 Interview with Kenneth Davisdon, Dutchess County Department
of Emergency Response. 7 June 2012. 16 Interview with Ed Schneyer,
Director of Emergency Preparedness for Suffolk County Department of
Fire,
Rescue and Emergency Services. 7 June 2012. 17 Interview with
John Bruckbauer, Nassau County oEM, 7 June 2012.
oveRvIew oF eXIsTIng sysTeMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
-
10
KnowledgeCenter is a web-based information management and
communications tool developed by KnowledgeCenter Inc. and used by
Pike County, PA. KnowledgeCenter is built on a SQL database and is
sold as an enterprise licensed solution. KnowledgeCenters database
can be hosted by a third party or installed in a local data center.
Its team ensures that all clients are running the most up to date
version of the software, which is extremely scalable and capable of
supporting a high volume of users.
KnowledgeCenter supports resource management in three ways: The
Resources Module: A tool that allows users to manage resources as
they are requested and deployed for an incident. While the
interface is simple and user-friendly, the underlying structure of
the Resources module can support the more-advanced supply chain
management (SCM) best-practices that would greatly assist
responders in managing resources for a large-scale,
multi-jurisdictional catastrophic incident.18
The Incoming Requests Dashboard: A tool that provides users with
an overview of met needs and unmet needs and gives them the option
to accept or decline resources based on what they already have.
The Incident Status Board: A tool that shows users the active
incidents in a defined area.
Jurisdictions Using KnowledgeCenter Version
Pennsylvania Emergency Management Agency (PEMA) Version
3.9.219
Pike County (as part of the Northeast Pennsylvanian Regional
Counter-Terrorism Task Force, which also includes Carbon,
Lackawanna, Lehigh, Monroe, Northampton, Susquehanna, and Wayne
Counties)
Version 3.9.220
18 Demonstration of KnowledgeCenter with John Gregory,
KnowledgeCenter Inc. 26 May 2010. 19 Interview with Dave Williams,
PEMA. June 2012. 20 Interview with Guy Miller, Monroe County office
of Emergency Services. May 2012.
KnowledgeCenter
oveRvIew oF eXIsTIng sysTeMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
-
11
WebEOC WebEoC is a web-based collaboration-oriented IMS
developed by ESi used by the Connecticut Department of Emergency
Management and Homeland Security (CT DEMHS) and will be rolled out
in all ten FEMA Regions beginning in August 2012.21
The software runs on a Microsoft SQL server with a backend
database consisting of multiple status boards which allow an agency
to generate, post, transmit, and share information in real-time
among its users.
While resource requests are posted to an Incident Status Board
for management of an individual incident, a Resources Status Board
enables users to manage an inventory of an agencys resources.22
Although the standard installation of WebEoC comes with a number of
status boards, clients must purchase additional optional features
in order to achieve interoperability with older versions of WebEoC
or other incident management solutions. These optional add-ons
include GIS integration status boards and the WebEoC NIMS-compliant
Resource Manager plug-in, which provides users with the capability
to catalog and deploy resources as prescribed through NIMS23 using
three main components:
Resource Inventory Requests Deployments24
Jurisdictions Using WebEOC Version
Connecticut Department of Emergency Management and Homeland
Security
Version 7.4.0.425
Connecticut Department of Emergency Management and Homeland
Security Administrative Regions (including Regions 1, 2, and 5
within the Region)
Version 7.4.0.426
21 Interview with Jose DosSantos, FEMA Region 2. September
2012.22 WebEoC Professional Version 7. ESi. Accessed from
http://www.esi911.com on 2 February 201023 WebEoC Resource Manager
2.0. ESi. Accessed from http://www.esi911.com on 2 February 2010.
24 http://www.slideshare.net/RIEMA/WebEoC-resource-manager accessed
June 2012. 25 Interview with John G. Gustafson, Emergency
Telecommunications Manager for Connecticut
Department of Emergency Management and Homeland Security. May
2012.26 Interview with John G. Gustafson, Emergency
Telecommunications Manager for Connecticut
Department of Emergency Management and Homeland Security. May
2012.
oveRvIew oF eXIsTIng sysTeMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
-
12 InFoRMATIon shARIng MeChAnIsMs | CoNFIDENTIAL. FoR oFFICIAL
USE oNLY
This section assesses the current information sharing
capabilities within the Region, including background information on
data standards.
At this time most information sharing in the Region at all
levels of government follows conventional pathways that include
in-person conversations, phone calls, radio, paper documents,
e-mail and facsimiles. These methods of ordering and tracking
resource requests limit visibility into the status of the request
and may duplicate processes and increase opportunities for
error.
The figure below depicts the current process of coordinating
resource requests among local, state and federal agencies using
these conventional pathways.
Current Request Process
Local and state partners use IMSs to manage resource requests,
but often the systems cannot talk to one another or share data. It
is also unclear whether these existing systems would be able to
manage a large surge in resource requests following a catastrophic
incident. In the three months following Hurricane Katrinas
landfall, FEMA received 864 unique Action Request Forms27 (ARF), a
900% increase on the per-disaster agency average of 95 ARFs.28 If a
catastrophe of similar magnitude were to affect the NY-NJ-CT-PA
Region, which is home to 22 million people, a 900% surge in
resource management activities could require an even greater
response. To manage such a response, agencies in this Region should
consider opportunities for incorporating information sharing
capabilities within their IMSs.
27 Miguel Jaller and Jose Holguin-Veras. Immediate Resource
Requirements After Hurricane Katrina: Policy Implications for
Disaster Response. (Rensselaer Polytechnic Institute, 2010), 7.
28 Federal Emergency Management Agency. Agency Information
Collection Activities: Proposed Collection; Comment Request.
Federal Register. 69, no. 39 (2004): 9350.
Information sharing Mechanisms
LOCAL The incident command requests a resource via phone or ICS
Form 215. The EOC manually inputs requests into its tracking system
and individually works with local partners to fill it.
STATE If the request cannot be filled locally, it is submitted
to the state EOC via phone, e-mail, and direct coordination, which
works individually with state resources, partners or EMAC to fill
it.
FEDERAL Requests unable to be filled with state resources or
EMAC are manually submitted to FEMA as Action Request Forms (ARFs).
FEMA coordinates with federal agencies and national resources to
fulfill the ARF.
CURRENTPROCESS BEGINS
LOCAL The incident command electronically requests a resource
with the EOC system, which shares information with local
partners/systems to fulfill it. Phones and ICS Form 215 can still
be used.
STATE Requests that cannot be fulfilled locally are
electronically transmitted to the state EOC's system, which shares
information with state asset databases and agencies to fill it. The
request may also be transmitted to an EMAC system.
FEDERAL Requests unable to be fulfilled through state resources
or EMAC are submitted to FEMA through an Action Request Form (ARF).
Ideally, FEMA develops new capabilities to accept and track ARFs
electronically.
PROPOSEDPROCESS BEGINS
OTHER LOCAL SYSTEMS
MUTUAL AID
EMACINCIDENT
EOC SYSTEM EOC SYSTEM EOC SYSTEM
LOCAL RESPONSE
AR F
FEDERALRESPONSE
STATE RESPONSE
?
!
@
?
!
LOCAL RESPONSE
STATE RESPONSE
215
?
!@
EMAC
ARF
@
FEDERALRESPONSE
INCIDENT
REGIONAL RESOURCE MANAGEMENT SOLUTION: RESOURCE REQUESTING
-
13
Connecticut
Information sharing has been automated in supply chain processes
in private sector oganzations for nearly two decades. Based largely
on an electronic data interchange (EDI) standard that is agreed
upon by multiple parties in a supply chain, these capabilities
allow private partners to automate many of the tasks which
emergency managers currently perform manually. Standards-based
automation would allow emergency managers to:
Streamline the resource request process by automating the
transmission of data on requests, fulfillment and deployment.
Reduce errors in resource requests by eliminating data-entry
duplication. Boost visibility into resource request and deployment
processes through real-time tracking of resources and seamless,
automated information sharing.
Automating the transmission of resource requests would greatly
improve the efficiency with which the Regions existing plans and
procedures are executed. The Region should look to interoperability
as a way to expand the capabilities of its existing plans and
procedures to efficiently manage resources in a catastrophe.
Proposed Request Process
In Connecticut, five CT DEMHS administrative regions coordinate
interactions between municipal and state government. Both CT DEMHS
and its administrative regions utilize WebEoC, and CT DEMHS has
granted all municipalities access to its WebEoC web-portal.
Accordingly, information across all levels of government in
Connecticut can be managed through WebEoCs various status boards,
which are shared among all users.
Connecticut is currently participating in a FEMA Region I pilot
project using Virtual USA. This product not only receives inputs
from WebEoC but allows integration of a variety of other GIS
products which use different platforms. This product is likely to
become the primary method for information sharing in New
England.29
29 Conversation with John G. Gustafson, Emergency
Telecommunications Manager for Connecticut Department of Emergency
Management and Homeland Security, May 2012.
InFoRMATIon shARIng MeChAnIsMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
Information sharing Mechanisms
LOCAL The incident command requests a resource via phone or ICS
Form 215. The EOC manually inputs requests into its tracking system
and individually works with local partners to fill it.
STATE If the request cannot be filled locally, it is submitted
to the state EOC via phone, e-mail, and direct coordination, which
works individually with state resources, partners or EMAC to fill
it.
FEDERAL Requests unable to be filled with state resources or
EMAC are manually submitted to FEMA as Action Request Forms (ARFs).
FEMA coordinates with federal agencies and national resources to
fulfill the ARF.
CURRENTPROCESS BEGINS
LOCAL The incident command electronically requests a resource
with the EOC system, which shares information with local
partners/systems to fulfill it. Phones and ICS Form 215 can still
be used.
STATE Requests that cannot be fulfilled locally are
electronically transmitted to the state EOC's system, which shares
information with state asset databases and agencies to fill it. The
request may also be transmitted to an EMAC system.
FEDERAL Requests unable to be fulfilled through state resources
or EMAC are submitted to FEMA through an Action Request Form (ARF).
Ideally, FEMA develops new capabilities to accept and track ARFs
electronically.
PROPOSEDPROCESS BEGINS
OTHER LOCAL SYSTEMS
MUTUAL AID
EMACINCIDENT
EOC SYSTEM EOC SYSTEM EOC SYSTEM
LOCAL RESPONSE
AR F
FEDERALRESPONSE
STATE RESPONSE
?
!
@
?
!
LOCAL RESPONSE
STATE RESPONSE
215
?
!@
EMAC
ARF
@
FEDERALRESPONSE
INCIDENT
REGIONAL RESOURCE MANAGEMENT SOLUTION: RESOURCE REQUESTING
-
14
In New Jersey, all county-level offices of emergency management
(oEM) and the state-level New Jersey office of Emergency Management
(NJ oEM) use E Team. Although the same IMS is used throughout the
state, discussions with various New Jersey state and county
agencies suggest that the majority of information is shared via
conventional pathways such as e-mail, phone and fax.
NJ oEM is spearheading an effort to upgrade the states version
of E Team 2.4 to version 9.5, the latest release of the software
from NC4; the states upgrade to version 9.5 is scheduled for
completion in the summer of 2012. The state plans to transfer all
data and consolidate all servers onto one cloud-based server
maintained at a facility in central New Jersey.30 once the transfer
is complete, all users in New Jersey will be able to use the system
through a standard internet connection. This will make information
sharing among users of New Jerseys E Team easier and more
reliable.
Due to New York States strong home-rule tradition, county-level
oEMs have complete authority over the choice and use of a IMS,
resulting in a wide variety of IMSs in use across the state. The
New York State Division of Homeland Security and Emergency
Management (NYS DHSES), along with several county oEMs such as
Westchester, Rockland and orange County, use Buffalo Computer
Graphics (BCG) DisasterLAN. Entities that use DisasterLAN version
7.3.1 or above can communicate with one another directly from
system to system using DisasterLAN-to-DisasterLAN messaging, or via
interoperable standards such as EDXL-DE, and CAP. County oEMs that
do not own their own DisasterLAN can either use the States
DisasterLAN web portal, email, or IPAWS-oPEN to convey information
to the state. All DisasterLAN systems on version 8.0.5 and above,
such as New York State and Rockland County, can also communicate
over the IPAWS-oPEN 3.0 communication network using CAP, EDXL-DE,
EDXL-RM, and CMAS.31
Dutchess County, New York City (NYC), Nassau, and Suffolk use
different versions of E Team. NC4s latest release of E Team version
9 allows users to customize the formats of resource messages, such
as requests and responses, to be compatible with other systems on
the receiving end.32 However, only the latest version 9 release of
E Team, available since early 2011, provides this functionality,
and it requires experienced information technology specialists and
programmers to be properly configured.
30 Interview with Tom Rafferty, Emergency Management Section of
the New Jersey State Police. 12 March 2010.
31 Interview with Patrick Cerra, Buffalo Computer Graphics, July
2012. 32 Interview with Erik Kant, NC4. 20 May 2010.
new Jersey
new york
InFoRMATIon shARIng MeChAnIsMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
-
15
NYC oEM and NYS DHSES have been working together to improve
interoperable data-sharing between E Team and DisasterLAN by
utilizing a standard called Emergency Data Exchange Language
Resource Messages (EDXL-RM). Both agencies are working on
transmitting resource requests from the local to the state level by
leveraging the interoperable message module of DisasterLAN with the
custom forms capabilities of E Team. NYC oEM has successfully
exported a resource request report from E Team, wrapped it in
Emergency Data Exchange Language - Distribution Element (EDXL-DE)
and posted it to the Integrated Public Alert Warning System
(IPAWS); this is discussed in greater detail on p. 22 in the
section titled, Implementing EDXL-RM in the Region. once NYC oEM
can convert the standard resource request into a valid EDXL-RM
message, an end-to-end message exchange test will be conducted with
New York State.33
Putnam County uses a customized IMS unique to its jurisdiction.
This custom system runs on a SQL platform and is used to track the
status of county and state emergency logistics operations using
editable and non-editable timestamps. It also has the ability to
track fire department, emergency medical service (EMS), and
hospital availability, Indian Point emergency levels, and all
traffic incidents, including details on who is assigned to the
incident and the estimated time for clearing. While it has a mail
module that allows tracked and recorded messages to be sent to
other users of the same system, it does not currently have any data
sharing or interoperability capabilities with other IMSs.34 The
eight county-level agencies of the Northeast Pennsylvania Counter
Terrorism Task Force (NEPACRTTF), the Southeastern Pennsylvania
Regional Task Force (SEPARTF), and the Pennsylvania Emergency
Management Agency (PEMA) have already developed specific
operational linkages between their IMSs. PEMA recently decided to
use KnowledgeCenter as its IMS, and will provide the same link that
it has with NEPARCTTF & SEPARTF to all other county emergency
management agencies within the Commonwealth.
This capability will allow county-level users to automatically
transmit resource requests to the Pennsylvania Emergency Management
Agency (PEMA) EoC when they cannot be fulfilled at the
county-level. This transmission is initiated by Knowledge Center
users with a simple Yes to send the request to the state. If a user
selects No they can still retrieve the request at any time and
change the answer to send the request to the state. When a user
selects to send the request to the state (Yes selection), the user
sees a visual confirming successful transmission, date, time,
resources specifically requested, and an ID reference.
33 Interview with Mark Frankel, NYC oEM June 2012.34 Interview
with Tom Lannon, Putnam County oEM. June 2012.
Pennsylvania
InFoRMATIon shARIng MeChAnIsMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
-
16
This straight-forward linkage may be considered a best practice
in the Region; a simple Yes or No selection is all that is required
of the user to share information, and additional automation
processes remain in the background, allowing the user to continue
their roles in the agencys existing plans and procedures.35
At present, each of the four state Emergency Management
Associations (EMA) in the Region uses a different IMS. As such,
state-to-state Emergency Management Assistance Compact (EMAC)
resource requests are usually transmitted along conventional
pathways such as e-mail, phone and fax. The requestor will likely
use the National Emergency Management Association (NEMA)
Requisition A form. NEMA also maintains a state-to-state
communications portal that can be used to track these requests, but
it is not presently compatible with the Regions IMSs.36
If requests cannot be fulfilled at the state level, the state
will submit an Action Request Form (ARF) to FEMA. The ARF is
usually submitted electronically, as a .DoC or .PDF37 that has been
attached to an e-mail, or is submitted as a hard copy. All ARFs
must be signed by the state governor or their designee and the
federal government only recognizes paper for this process at the
moment.
However, this process may change in the future once every FEMA
region begins using WebEoC and is able to receive web-based
electronic requests directly into that system. WebEoC is the IMS
currently used at some jurisdictional level by 46 of the 50 states,
and will be rolled out to all FEMA regions beginning in August
2012.38
FEMAs Logistics and Supply Chain Management System (LSCMS) is
another resource management system modeled on 3PL and SCM
best-practices that is used to fulfill orders and track resource
requests, shipments and receipts. once released, FEMAs LSCMS should
boost the agencys capabilities for managing resources and will
likely result in better tracking visibility and command and control
of critical resources.39
35 Interview with Guy Miller, Monroe County PA oEM, and Dave
Williams, PEMA. June 2012. 36 Interview with Captain Howard Butt,
EMAC State Coordinator for New Jersey State Police. 24 March 2010.
37 Miguel Jaller and Jose Holguin-Veras. Immediate Resource
Requirements After Hurricane Katrina: Policy
Implications for Disaster Response. (Rensselaer Polytechnic
Institute, 2010). 38 Interview with Jason Wind, FEMA Region II. 20
June, 2012. 39 Interview with Jason Wind, FEMA Region II. 20 June,
2012.
state-to-state (eMAC)
Federal
InFoRMATIon shARIng MeChAnIsMs | CoNFIDENTIAL. FoR oFFICIAL USE
oNLY
-
17
Common Alerting
Protocol (CAP)
emergency Data exchange
Language - Distribution
element (eDXL-De)
InFoRMATIon shARIng CAPAbILITIes | CoNFIDENTIAL. FoR oFFICIAL
USE oNLY
Information sharing Capabilities
This section highlights the current standards that are available
and used for information sharing within the Region and among
IMSs.
All of the Regions incident management systems support some
degree of standards-based sharing capabilities through adoption of
the Common Alerting Protocol (CAP), part of the Emergency Data
Exchange Language (EDXL) suite of standards developed by the
organization for the Advancement of Structured Information Systems
(oASIS). Most IMSs are already capable of handling CAP messages for
weather service warnings, amber alerts and other simple alert
messages. Key principles include:
Interoperability: The CAP Alert Message should provide a means
for interoperable exchange of alerts and notifications among all
emergency information systems.
Completeness: The CAP Alert Message format should provide for
all the elements of an effective public warning message.
Simple implementation: The design should not place undue burdens
of complexity on technical implementers.
Simple XML and portable structure: Although primary use of the
CAP Alert Message is as an XML document, the format should be
adaptable to other coding schemes.
Multi-use format: one message schema supports multiple message
types (alert, update, cancellations, acknowledgements, error
messages) in various applications (actual, exercise, test, system
message).
Familiarity: The data elements and code values should be
meaningful to warning originators and non-expert recipients
alike.
Interdisciplinary and international utility: The design should
be applicable worldwide and allow for a broad range of public
safety/emergency management applications.40
The primary goal of EDXL-DE is to serve as a container to
facilitate the routing of properly formatted XML messages. The
relationship between EDXL-DE and EDXL-RM is similar to the
relationship between an envelope and the actual letter it contains.
The EDXL-DE wraps the EDXL-RM content that would comprise the
resource message and contains key routing information such as the
name and address of the recipient and sender. The key principles of
EDXL-DE include:
Provide an open Container Model to enable dissemination of one
or more emergency messages.
Provide flexible mechanisms to inform message routing and/or
processing decisions. Enable dissemination of messages based on
geographic delivery area. Enable use and re-use of data content and
models developed by other initiatives. Support process-driven
specific messaging needs across emergency professions. Support
everyday events and incident preparedness, as well as disasters.
Facilitate information sharing and data exchange among local,
state, tribal, national and non-governmental organizations that
provide emergency response services.
Utilize a multi-use format so that one message schema supports
multiple message types in various applications.41
40
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html.
Accessed 7 June, 2012. 41
http://www.oasis-open.org/committees/download.php/17227/EDXL-DE_Spec_v1.0.html.
Accessed on
7 June 2012.
-
18
use of established
standards
Each IMS approaches interoperable messaging standards
differently. The following table summarizes existing
standards-based information sharing capabilities currently observed
in the Region.
Information sharing Capabilities DisasterLAn e Team
KnowledgeCenter webeoC
Native Data Format SQL x x x
other x(Server Agnostic)
Casting Pushes data automatically or at set intervals x x x
x
Transmits CAP messages x x x x
Wraps data in EDXL-DE standard x x x x
Can send any current EDXL Standard (Excluding CAP) x x x x
Can send via non-EDXL NIEM compliant Standard x x x x
Can send Commercial Mobile Alert System (CMAS) messages x x
Routing Transform data based on user-defined principles x x x
x
Routes messages based on EDXL-DE standard x x x x
Can route via non-EDXL NIEM compliant Standard x x x x
Routes messages based on publish / subscribe x x x x
Utilizes an enterprise service bus (ESB) x x x
Receiving Pulls data automatically / at set intervals x x x
x
Receives CAP messages x x x x
Receives EDXL-DE messages x x x x
Receives any current EDXL Standard (Excluding CAP) x x x x
Can receive via non-EDXL NIEM compliant Standard (Excluding CAP)
x x x x
General Customizable reports x x x x
Adapters for legacy systems N/A x N/A x
User-interface to present shared / aggregated data x x x x
Minimal impact to existing plans / processes x x x x
Role-based data-sharing and security model x x x x
InFoRMATIon shARIng CAPAbILITIes | CoNFIDENTIAL. FoR oFFICIAL
USE oNLY
-
oveRvIew | CoNFIDENTIAL. FoR oFFICIAL USE oNLY 19
Information sharing Capabilities DisasterLAn e Team
KnowledgeCenter webeoC
Native Data Format SQL x x x
other x(Server Agnostic)
Casting Pushes data automatically or at set intervals x x x
x
Transmits CAP messages x x x x
Wraps data in EDXL-DE standard x x x x
Can send any current EDXL Standard (Excluding CAP) x x x x
Can send via non-EDXL NIEM compliant Standard x x x x
Can send Commercial Mobile Alert System (CMAS) messages x x
Routing Transform data based on user-defined principles x x x
x
Routes messages based on EDXL-DE standard x x x x
Can route via non-EDXL NIEM compliant Standard x x x x
Routes messages based on publish / subscribe x x x x
Utilizes an enterprise service bus (ESB) x x x
Receiving Pulls data automatically / at set intervals x x x
x
Receives CAP messages x x x x
Receives EDXL-DE messages x x x x
Receives any current EDXL Standard (Excluding CAP) x x x x
Can receive via non-EDXL NIEM compliant Standard (Excluding CAP)
x x x x
General Customizable reports x x x x
Adapters for legacy systems N/A x N/A x
User-interface to present shared / aggregated data x x x x
Minimal impact to existing plans / processes x x x x
Role-based data-sharing and security model x x x x
InFoRMATIon shARIng CAPAbILITIes | CoNFIDENTIAL. FoR oFFICIAL
USE oNLY
-
20 ADoPTIng eDXL-RM | CoNFIDENTIAL. FoR oFFICIAL USE oNLY
eDXL-RM background
and overview
eDXL-RM Technical overview
The Emergency Data Exchange Language Resource Messaging
(EDXL-RM) is a recognized messaging standard that can support the
Regions existing resource management practices while expanding the
capability for coordination between different jurisdictions,
agencies, and levels of government.
In June 2010, the Regional Information Management Solution
(RIMS) Planning Team agreed to recommend the EDXL-RM standard for
adoption by the Region.42 The Planning Team generated consensus for
a standards-based approach as the only viable way to address
current interoperability problems and create new opportunities for
resource management, resource request linking and field asset
visibility.
EDXL-RM is a standard that brings structure to the way resource
data is shared between agencies when resources are requested and
deployed in emergencies. It is part of a broader initiative known
as Emergency Data Exchange Language (EDXL), a group of structured
message formats intended to create data-sharing capabilities for
all sections of the Incident Command System (ICS), and developed as
a result of interoperability initiatives from:
The Presidential e-Government Initiative The Department of
Homeland Security (DHS) Science and Technology Directorate
(S&T)s office for Interoperability and Compatibility (oIC)
The Disaster Management Practitioner Steering Group (DM-PSG)
EDXL-RM was adopted in 2008 by the Emergency Management
Technical Committee of the organization for the Advancement of
Structured Information Standards (oASIS), a non-profit consortium
for the development and adoption of open standards in public
information sharing. EDXL-RM has also been registered and accepted
as a National Information Exchange Model (NIEM) 2.0 Conformant
Schema, making it the only publicly published data-sharing standard
available to projects that require NIEM-compliance.
NIEM-compliance is currently required by DHS and the US
Department of Justice for interagency information exchange43 as
well as for certain DHS grants for state and local projects. As a
NIEM-conformant standard, EDXL-RM appears to be the only recognized
standard for emergency management resource messaging in the United
States and will be required for all recipients of federal grants
for projects implementing XML-based information exchange.44
EDXL-RM is an XML-based standard to support: Discovery: locating
a resource to fulfill a request Ordering: procuring a discovered
resource Deployment: tracking an ordered resource until it is
received by its requestor
42 RIMS Planning Team Meeting Minutes, June 2010. 43 B2-15
National Information Exchange Model (NIEM). Department of Homeland
Security. Acquisition
Instruction / Guidebook #102-01-001: Interim Version 1.9,
Appendix B, November 2008. 44 Grant Recipient IEPD Registration
Requirements. NIEM Program Management office. NIEM
Implementation
Guidelines. 9 June 2010. Accessed on 10 June 2010 from
http://www.niem.gov/implementationguide.php.
Adopting eDXL-RM
-
21ADoPTIng eDXL-RM | CoNFIDENTIAL. FoR oFFICIAL USE oNLY
The EDXL-RM standard message enables information sharing between
resource consumers and resource suppliers, and can send and respond
to the following requests:
Requests for Information, such as determining if a state agency
can supply a generator. Requests for Quotations, for linkages to
agency procurement and accounting systems, such as determining and
authorizing rental costs of a crane from a private vendor.
Unsolicited Offers of Resources, such as offers of support from
VoADs. Requests for Resources, such as formally procuring a
generator from a state agency. Requisitions for Resources, for
eventual linkages to agency procurement and accounting systems,
such as issuing a purchase order to private vendor.
Requests for Return of a Resource, such as a state agency
requesting the return of a generator.
Requests for Deployment Status, such as requests for GPS
coordinates to update a resource request with the location status
of a shipment that is in transit for delivery.
Release a Resource for Deployment, such as issuing formal
instructions to an agency or private vendor for delivery of a
resource to an incident location or staging area.
Requests to Extend Deployment Duration, such as requests to
continue renting a resource from a private vendor when a need
exists.
These messages are standardized into 16 different schema, or
standard message templates for data-sharing. The following figure
shows the different message behaviors under EDXL-RM.
Discovery
ordering
Deployment
ResouRCeConsuMeR
ResouRCesuPPLIeR
Request Information
Response to Request InformationRequest Quote
Response to Request Quote
offer unsolicited Resource
ResouRCeConsuMeR
ResouRCesuPPLIeR
Request Resource
Response to Request ResourceRequisition Resource
Commit Resource
ResouRCeConsuMeR
ResouRCesuPPLIeR
Request ReturnResponse to Request Return
Request Resource Deployment statusReport Resource Deployment
status
Release ResourceRequest extended Deployment Duration
Response to Request extended Deployment Duration
-
22 IMPLeMenTIng eDXL-RM In The RegIon | CoNFIDENTIAL. FoR
oFFICIAL USE oNLY
This section examines possibilities for the Regions IMSs to
become compliant to the EDXL-RM standard and how EDXL-RM messages
can be shared between jurisdictions.
All the IMSs in the Region currently provide a method for
interoperable data sharing that supports resource management and
corresponding operational coordination. However, interoperability
is not necessarily part of the off-the-shelf solution and may need
to be designed around systems already in place. The Region should
look into drawing upon interoperable data-sharing capabilities that
support resource management.
All of the IMSs in use in the Region can maintain an inventory
of available resources and display a list of resource requests and
status. The table below lists the tools and capabilities needed for
each IMS to support resource management. Further details and
sources are included on the following page.
Implementing eDXL-RM in the Region
Capabilities to support Resource Management Among IMss
DisasterLAn