BCG Response to Sandy Draft AAR

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

APPENDIX B

NIMS-Step Evaluation Summary Report

19

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.


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.


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


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.


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


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


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


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


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


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

Documents

BCG Response to Sandy Draft AAR