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 maj or 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 never crashed duri ng Sandy operations. 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 a ccessing 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 withi n in NY, as as well as num erous other loc ations across t he US US and 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 York to California. Additionally, within NYS 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 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 ful ly NIMSNIMScompli ant and and can communi cate with any other system that compli es with federal federal interoperability standards. DLAN 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 o n-site support dur ing Sandy, the vast majority of which w as not DLAN NYSOEM is understaffed, and many key personnel were were shifted related. As related. As noted in the report, NYSOEM to the ROC in NYC leaving the EOC even even more shorthanded. BCG personnel have extensive extensive state-wide activation experience and were able to help fill some of the gaps, providing just intime 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 f unctio nal asset asset tracking and resourc es module and and various i terations of these mod ules have been recomm ended to NYSOEM NYSOEM befor befor e, during , and after Sandy. 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 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 employees provi ded just-intime training for t hose unfamiliar wit h NYSO NYSOEM EM procedures procedures and polici es as well well as wi th 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, synopsis, the Sandy After Action Report draft included several 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 o ur personnel who, as stated previously, were an active part of NYSOEM’s 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 a ccusations laid against DLAN in this report and it is our hope that this information will give a more accurate assessment of NYSEOM’s response to Sandy and both DLAN’s use and BCG’s participation in this response.

2

Full Response  As the vendor of the DLAN DLAN Crisis Incident Management System, BCG takes exception to many of the libelous and inaccurate assertions issued issued in the Sandy After Action 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 report’s inaccuracies below. Should any party be interested in in discussing the issues with with us, we would be happy to do so. Report 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 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. activities performed by BCG staff staff during Sandy. Just-in-time  Appen  Ap pendi di x A  provides a list of the activities training on DLAN was also provided, pr ovided, as would be expected with any software system utilized by mutual-aid personnel unfamiliar with both the software 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 System to have passed every NIMS-STEP evaluation test for interoperability and NIMS-compliance (see App (see App endix end ix B for a summary of FEMA’s FEMA’s report). DLAN supports the CAP CAP & EDXL data interoperability interoperability standards promoted by FEMA/DHS FEMA/DHS in addition to email and web services data exchange. exchange. BCG will not comment on the ability or willingness of other systems to share information interoperably, but will assert our ability 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 always been at the forefront of this information information exchange effort. See  Appen  Ap pendi di x C for C  for more information on the IEM interoperability effort. While it is true th at NYC, Suffolk and Nassau Counties utilize systems other than DLAN, many

3

other counties do utilize DLAN systems. These include Chautauqua, Cattaraugus, Cattaraugus, Erie, Niagara County, Ontario, Rockland, Westchester, Livingston, and Orange, as well as the Seneca Nation of Indians. DLAN is also utilized utilized by the NYS Department of Military and Naval  Affairs as well as our cross-border cross-border Canadian partners in the Ontario and Halton Halton regions of Canada. Additionally, since DLAN 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 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 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 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 system to them. BCG has, and continues 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 r eview of Sandy, and one of our recommendations going forward is th at NYSOEM better utilize video and web-based training. For example, a just-in-time video video training module could be produced so that when when outof-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 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 ag ency users.

5

Report 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 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 of specific entered requests is difficult, difficult, making making management and planning for those resources and assignments challenging; DLAN does not readily allow users to generate custom custom reports - the DLAN 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 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 other’s systems, resource management will continue to be an issue.” Response 3: The fact that DLAN was was designed with NIMS interoperability requirements in mind has been previously addressed and will not be revisited here.  As for the claim that entering entering a ticket is time consuming, consuming, this is partially true. However 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 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 r esources 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 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 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 Att (see Att achmen ach mentt D). 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 request without gathering the necessary information. 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 will speed up ticket entry, but you you will also have a fraction of the information necessary to deploy resources and will increase the manpower ma npower and time required to ultimately collect this information in the end. This is a pay-me-now or pay-melater 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 NYSOEM today is the result of years worth of use, ideas, suggestions, suggestions, and improvements. BCG truly values 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 system easier to use. We are always open to ideas and suggestions to improve the product. But, general statements without without specific context and suggestions suggestions for improvement cannot be addressed. Regarding the statement that tracking of r equests is difficult, we disagree on several fronts. First, every resource request in the system is given a unique 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 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 utilize these resource tracking tools, but they are available to them on their system. In terms of reporting, the assertion a ssertion that “DLAN does not readily allow users to generate custom reports” , or what some other systems systems refer to as “boards” and/or “inboxes” “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 doesn’t 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 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, reports, they frankly were were so overwhelmed with other duties that BCG staff stepped in to help. While we previously talked about inter operability, it is probably worth directly addressing ag ain 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 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 NYS utilize DLAN than WebEOC and E-Team combined. It might be worth pointing out how the State of Minnesota addressed 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 didn’t support support the FEMA/DHS FEMA/DHS IPAWS IPAWS system for data exchange, BCG developed a custom web service to integrate with Knowledge Center’s proprietary communications system. system. Today, both DLAN and Knowledge Knowledge Center share information between systems in MN. MN. The point being made here is that the issue 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 NYSOEM staff to identify, design, and cost out the “ideal” “ ideal” asset management system that could be used by their logistics staff. They envisioned a state-of-the-art web-based web-based system that utilizes utilizes bar-coding, mobile hand-held devices, and GPS location location tracking devices as the ultimate ultimate solution. The proposed BCG approach was to take DLAN’s 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 NYSOEM with multiple cost-effective cost-effective proposals, in advance of Sandy, that never never gained any traction within the agency. agency. Specifically, the following proposals were provided to NYSOEM: NYSOEM:

8

Date 01/06/2009 10/16/2012 10/16/2012 10/16/2012

Propos al Number  Q1913 [Web-Based Interoperable Logistics Management System] Q2390 [Resource Module] Q2392 [Advanced Resource Integrations] Q2393 [Ticket Manager / Resource Integration]

9

Report Report Assertion 4: “DLAN crashed during Sandy operations (though oth er 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 pr oduct, 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 ab ility 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 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 Internet to your home goes out and you you cannot reach cnn.com, you should not assume assume that CNN is broken and blame CNN. 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 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 everything seemed faster for external external users. However, later that day at around 4:50 PM DLAN could not be accessed externally. externally. DLAN continued to function internally at the EOC and for any users connected via a VPN VPN connection. External user outside the DHSES network could not reach DLAN, DHSES email, DHSES Sharepoint servers, and other DHSES systems. systems. This clearly was a bandwidth-related issue related to DHSES’ DHSES’ network and not a DLAN issue. issue. BCG again spoke with 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 accessed because of this Internet issue. issue. Again, we must point out out that DLAN did not crash, but may have been inaccessible to certain users because of the Internet bandwidth issue. Initially, it was believed believed that there was a failure in some external external equipment on the AT&T network network that served NYSOEM. NYSOEM. However, the ultimate issue 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 untoward effect of saturating the NYSOEM NYSOEM network network with data requests thereby blocking or preventing other 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 wireless network. Some users in the Albany EOC lost wireless connectivity and thus access 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 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 people’s ability to access access DLAN. But again, this was was not a DLAN failure.  At 10:15 AM on 11/01/2012, NYSOEM NYSOEM IT IT needed to failover one of their SQL 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 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) (SAN) in order to replace a failed controller card. The maintenance interval ran from 12:15 to 1:30 1:30 PM. Because the DLAN database, like most other NYSOEM data stores, resides on the Piller SAN, DLAN was briefly inaccessible inaccessible during this outage. Again, DLAN inaccessibility inaccessibility was not the result of a failure of DLAN.

11

Report 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 agency’s dysfunction. dysfunction. The system has few supporters supporters and many detractors, does not “play well with other s,” 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 ag ency at any level in New York” to employ DLAN. This is incorrect, and one can only assume written to dimunitize 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 York to California. Additionally, within NYS 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 FEMA evaluated systems for use within within their organization, DLAN rated as “excellent” overall with a rating of “outstanding” for past performance based upon customer interviews (see Att (see Att achmen ach mentt E ). Regarding the statement that DLAN “does not seem to do anything better than other, more widely accepted, competing systems”, systems”, we cannot disagree more strongly. strongly. We are intimately familiar with competing systems, and feel strongly that DLAN is unique in the way information infor mation is managed in a workflow-based manner. In fact, there is an exhaustive 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 f ull IPAWS-OPEN IPAWS-OPEN integration, integration with NY-Alert, support for FEMA Project Worksheet finance tracking, and unified communications tools for monitoring 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 doesn’t do anything for them but they can’t 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 systems and see how their system system performed in a large event. After conducting an exhaustive, exhaustive, fair comparison, we are confident that you will appreciate the capabilities, features and flexibility that DLAN offers. 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 ig nored DLAN supporters or specifically sought out DLAN detractors. One can only question the author’s author’s motivations.

12

Report Report Assertion 6: “A modern asset tracking system tied to DLAN (or some other incident management support software package) and to the State’s 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. assessment. In fact, as stated previously, previously, we have advocated for and proposed such a system to NYSOEM NYSOEM on previous occasions. 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 11/05/2012

Propos al Number  Q2400 [DLAN Ticket #102860]

BCG went as far as to bringing bring ing our asset tracking logistics expert in fr om 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. devices. Each asset would have have been trackable on a map and complete location reporting would have been possible. possible. BCG could have initiated initiated the fielddeployment 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 robust asset tracking system system should be tied to DLAN.

Report 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 DLAN “is not accepted by the the local communities…”. In fact, DLAN is used successfully and enthusiastically enthusiastically used by numerous counties throughout NYS. Many of the comments we we have heard from counties is that while while they want to utilize DLAN, they have been prohibited from doing so by NYSOEM.  Additionally, the DLAN customer customer base in NYS continues continues to grow with several counties currently interested in adding DLAN to their incident management tool set.

13

Report 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, 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 u nderstood by the authors of this re port, 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, 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 DLAN’s configuration and capabilities has led to many of the inaccuracies of this report. report. As stated at the beginning of this document, we must also reiterate that BCG was never interviewed during th e report creation process. Had BCG been given the opportunity 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, NYSOEM, BCG BCG was called upon to provide on-site staffing staffing to NYSOEM NYSOEM for the response to Hurricane Sandy – both pre-landfall and post-landfall. 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 req uested staffing levels, and upon execution of a work order, BCG 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 issue another work order and BCG would would maintain or deploy personnel as required. This process repeated until such time time that NYSOEM 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 willing to provide any type of support requested by NYSOEM. NYSOEM. Below is a sampling of the activities/services activities/services provided by BCG: Provided 24/7 support to the Albany EOC ● Served as liaison liaison to incoming EMAC teams and provided: ● Just-in-time training on DisasterLAN ○ Training on NYSOEM operating procedures, procedures, policy and workflow ○ Orientation to EOC facilities and introduction to personnel ○ Creation of of user user accounts accounts and configuration configuration of of required security settings ○ BCG typically typically BCG BCG typically typically ran one large group training and 20-25 small training ○ sessions each shift. Provided DLAN DLAN and other job duty training training to NYS agency personnel as the the rotated in● and-out of the EOC Built training videos and quick reference sheets to to help supplement NYSOEM NYSOEM workflow ● and DLAN training Just-in-time web web and over the phone training for NYSOEM NYSOEM regional staff deployed to ● affected counties ● Created DLAN user accounts, 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 needs of the ● NYSOEM EOC, NYSOEM ROC, NYSOEM Regions, Nassau County, Suffolk County, State Agencies, and other affected 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 stages of of processing by NYSOEM NYSOEM ○ Provided custom data exportation and importation Supported NYSOEM NYSOEM IT with server server equipment troubleshooting and advanced NYSOEM NYSOEM process support to overcome NYSOEM technology issues as needed. Activities included: Supporting NYSOEM NYSOEM Operations when when the Oracle Pillar Pillar SAN failed on 11/8/2012 11/8/2012 ○ Supporting NYSOEM NYSOEM Operations with with paper copies of tickets tickets and backed up ○ reports when the Oracle Pillar SAN failed on 11/23/2012 ○ Troubleshooting of the NYSOEM NYSOEM wireless network which which became overloaded by users several times during the incident ○ Troubleshooting of the NYSOEM NYSOEM external network network which 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 DMNA’s DLAN server hardware hardware hosted in NYSOEM’s NYSOEM’s datacenter several times during the incident ○ Assisting with backups backups of DMNA’s and NYSOEM’s NYSOEM’s DLAN DLAN servers several times during the incident Supported NY-Alert NY-Alert with server equipment troubleshooting and advanced NY-Alert process support to overcome NY-Alert NY-Alert technology issues as needed. Activities included: Spent a large amount of time time monitoring and troubleshooting troubleshooting issues that ○ occurred under heavy system load, which eventually led to the determination that NY-Alert did not have enough Email Email Servers. Assisted Kevin Kevin Ross in configuring 4 new email servers. Created a “Software Load Load Balancer” in NY-Alert 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 support Hurricane Sandy activities including: Added the ability to dynamically dynamically add new Email Servers Servers without without interrupting ○ service Added a special managed re-try handler for a particular types types of issues NY-Alert NY-Alert ○ encountered with NWS’s 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 avoid issues where, ○ under heavy load, old data would remain cached too long instead of updating when it should Provided custom custom NY-Alert NY-Alert importation and configuration to support a transfer for NYC alerting system to NY-Alert Routine hourly backups of tickets for NYSOEM NYSOEM Operations Routine hourly backups of of status board slides slides for NYSOEM Planning Configuration changes to DLAN DLAN modules to support support NYSOEM Branches ○

● ●

●

●

●

● ● ●

16

●

● ●

●

Research and custom integration integration with Gentrifi AVL AVL and WDT weather data feeds to support NYSOEM EOC operations Custom data cleanup to fully fill out tickets tickets for people who entered incomplete data Provided requested support to New York York City Regional Operations Center. Activities Activities included: Staffed the New York City City Regional Regional Operations Center to provide provide training on ○ NYSOEM workflow, NYSOEM policies and procedures, and re source requesting on DLAN for State Police, Public Service Commission, and military personnel coming to support the operation ○ Coordinated with NYS GIS (Frank (Frank Winters) to support GIS data data sharing needs throughout the incident Created graphical maps of proposed floor plan layouts ○ Worked with with NYSOEM NYSOEM staff 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 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 of network, network, Internet, and bandwidth bandwidth issues to help support DHSES IT

17

18

 APPENDIX B NIMS-S NIMS-Step tep Evaluatio n Summ ary Report

19

20

21

22

23

 APPENDIX C

Regional Regional Logi stics Program

24

NY NJ CT PA

REGIONAL LOGISTICS PROGRAM

DISASTER LOGISTICS

Regional Data Interoperability & Resource Management Assessment Paper

Sept 2012

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 o f Contents Conten ts

Preface

2

Using this Document

3

Overview

4

Overview of Existing Systems

6

12

Information Sharing Mechanisms

Connecticut New Jersey New York Pennsylvania State-to-State (EMAC) Federal

14 14 15 16 16

Information Sharing Capabilities

Existing Standards-Based Information Sharing Capabilities

17

Adopting EDXL-RM

20

Implementing EDXLEDXLRM in the Region

22

Establishing Regional Operational Coordination

25

Appendices

References

Appendix A: NIMS-Supporting Technology Evaluation Project (STEP) Appendix B: Additional Research Appendix C: Additional Resources Resources

28

Glossary Acronyms Bibliography Planning Team List Contact Information Informatio n

33

29 32

35 37 39 40

Preface

Established in 2008, the Regional Catastrophic Preparedness Grant Program (RCPGP) (RCPGP) is a groundbreaking groundbreaking Department of Homeland Security initiative to encourage collaborative emergency planning in America’s largest regions. The New York-New Jersey-Connecticut-Pennsylvania Jersey-Connec ticut-Pennsylvania (NY-NJ-CT-PA (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 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 multi-jurisdictional Regional Information Management Solution (RIMS) Planning Team. The document is focused on jurisdictions in the NY-NJ-CT-PA NY-NJ-CT-PA RCPGP Project Site (hereafter, (hereaf ter, “the Region”); however h owever,, any agency or jurisdiction is welcome to use this information in any capacity in which it may be found useful.

2

Using this Document

This Assessment Paper summarizes the objectives and presents the conclusions and findings of the t he Regional Resource Management Solution (RRMS) initiative.

Find project goals, objectives, and status.

4

Find an overview of existing technology systems in the Region.

6

Review current mechanisms for information sharing in the Region.

12

Learn about EDXL-RM and its potential as a data interoperability solution.

20

The RRMS Regional Data Interoperability and Resource Management Assessment Paper is part of a comprehensive 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, toolk its, can be b e found at http:/ h ttp:// /www.EmergencyLogist www.EmergencyLogistics.org. ics.org. Together, 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. USING THIS DOCUMENT | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

3

Overview

This document is designed to help logisticians develop plans to improve data-sharing capabilities in their incident management systems. The National Preparedness Preparedness Goal, published by the United States Department of Homeland Security (DHS) in September 20111, stresses the importance of operational coordination coordination and interoperable data communications between federal, state and local first responders. responders. It emphasizes maintaining maintaining a core capability for operational communications communications to “ensure “ensure the capacity for timely communications 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 maintain operational coordination coordination and operational communications. 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 resources are requested and deployed during disaster response.

Goal

Objectives

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.

Region’s 4 Evaluate potential middleware and other solutions that integrate with the Region’s current systems, seamlessly connecting multiple levels of government government and enhancing interoperable interoperable communications while allowing jurisdictions to keep their existing technology systems. 5 Evaluate potential solutions to improve the visibility of critical assets, resources, resources, supplies and equipment that are deployed after a disaster. disaster.

1

4

“Crosswalk of Target Target Capabilities to Core Core Capabilities”. FEMA . Access on May 16, 2012 www.fema.gov/pdf/prepared/crosswalk.pdf

OVERVIEW | CONFIDENTIAL. FOR OFFIC IAL USE ONLY

Project Status •

•

•

•

•

•

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 Pennsyl vania and beyond. beyond . The Planning Team Team played a critical role in developing the strategy for improving regional interoperability 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 interoperable data-sharing on any current or future technology projects. Compiled information on both challenges and best practices for regional interoperability interoperability and resource 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 Region’s 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.

OVERVIEW | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

5

Overview of Existing Systems

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 support s resource management and information sharing.

• • • •

Existing Technology within the Region

• • • •

In order to effectively manage resources a IMS user must be able to: Order and acquire resources Mobilize resources Track, inventory inventor y and report resources resou rces Facilitate resource reimbursement DisasterLAN™, DisasterLAN™, developed by Buffalo Computer Graphics E Team, Team, developed develo ped by NC4™ NC4 ™ KnowledgeCenter™, developed by KnowledgeCenter Inc. WebEOC®, developed by ESi®

County Agency Systems Disaster LAN

Version 8.0.5 Version 7.5.0 E Team

Version 9.5 Version 9.02 Version 6.x 6 .x Version 3.x

NY CT

Knowledge Center

Version 3.9.2 PA

NJ

Web EOC

Version ersi on 7.4.0.4 State Agency Systems

6

OVERVIEW OF EXISTING SYSTEMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

Evaluating IMSs for implementation

DisasterLAN™2, 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 agency’s paper-based processes.

DisasterLAN™

DisasterLAN™ Disaster LAN™ is a web-based web-based system that is built on an SQL server. The software is customizable, and sold as a per-site license. license. Because it is web-based, anyone anyone with proper security privileges and a web browser browser can access it. It can be deployed on a dedicated or shared server or can be hosted virtually at DisasterLAN’s™ DisasterLAN’s™ data center. DisasterLAN™ recommends 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 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 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 information management requirements requirements and can be used to manage NIMS typed resources and track the full lifecycle of a resource resource request, including its fulfillment and deployment. 4 Preplanning:  A tool that can be used to manage information on suppliers and stockpiles. Resources Resources can be matched to call center tickets requesting or donating resources. Interoperable Interoperable Messaging:5 A tool that can be used to send and receive standardsstandardscompliant messages, while allowing access to information (such as resource tickets, etc.) in a template-driven interface. 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), (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 3

Reviewed by Tim Masterson, DisasterLAN DisasterLAN software Manager, Manager, BCG. June 22, 2012 Buffalo Computer Computer Graphics. “DisasterLAN™ Call Call Center Ticket Ticket Manager.” Manager.” Buffalo Buffalo Computer Graphics. Accessed on 16 May 2012 from http://www http://www.buffaloco .buffalocomputergrap mputergraphics.com hics.com/ /documents/DLAN%2 document s/DLAN%20 0 Call%20Center%20Slick.pdf 4 Buffalo Computer Computer Graphics. Graphics. “DisasterLAN™ Preplanning Module.” Module.” Buffalo Computer Computer Graphics. Graphics. Accessed on 16 May 2012 from http://www http://www.buffaloco .buffalocomputergrap mputergraphics.com hics.com/ /documents/DLAN%2 document s/DLAN%20 0 Preplanning%20Slick.pdf 5 Buffalo Computer Computer Graphics. “DisasterLAN™ Interoperable Interoperable Messaging Messaging Module.” Accessed on 16 May 2012 from http://www.buffalocomputergra http://www.buffalocomputergraphics.co phics.com/ m/document documents/interop s/interoperable-mes erable-messaging saging.pdf .pdf 6 Results from each evaluation may be accessed accessed at www.rkb.us www.rkb.us (keyword (keyword STEP). Accessed Accessed June 2012.

OVERVIEW OF EXISTING SYSTEMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

7

E Team

Jurisdictions Using DisasterLAN

Version

New York State Division of Homeland Security and Emergency Management (NYS DHSES)

Version 8.0.57

Westchester Co County Of Office of of Em Emergency Ma Management

Version 7. 7.5.08

Orange County Division of Emergency Management

Version 7.5.0

Rockland County Department of Emergency Management

Version 8.0.59

NC4’s™ E Team, Team, a IMS used by N New ew Jersey and multiple multi ple agencies agencie s throughout New York State, provides users with interactive views on incident summaries, response operations, resource resource requests and deployments.10 E Team Team can be accessed using most web browsers browsers and the system is server agnostic, meaning that it can be run on Oracle, SQL, or other servers. System access and authentication authentication is controlled by a role-based data-sharing and security model that can be integrated with any existing Active Directory installation. Managing E Team’s back-end database requires no knowledge of database programming languages; data can be filtered and displayed via E Team’s Web Services architecture. architec ture. Although E Team Team is considered an off-the-shelf off-the-sh elf 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, resources, and tracks their availability, location and characteristics. 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, Masterson, DisasterLAN™ Software Software Manager Manager,, BCG. 22 June, 2012. 2012. 8 Westchester Westchester and Orange counties plan to upgrade upgrade to version 8.0.5 8.0.5 by Fall Fall 2012 as per Tim Tim Masterson, DisasterLAN™ Software Manager, Manager, BCG. June 2012. Confirmed by Patrick Cerra, Buffalo computer Graphics, July 2012. 9 Interview with Tim Masterson, Masterson, DisasterLAN™ Software Software Manager Manager,, BCG. 22 June 2012. 2012. 10 “E Team: Team: Functionality.” NC4™. Accessed from http://www.NC4.us/ETeam.php http://www.NC4.us/ETeam.php on 5 June 2012. 11 Interview with Eric Kant, Interoperability Interoperability Architect, Architect, NC4™. 19 June 2012.

8

OVERVIEW OF EXISTING SYSTEMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

Jurisdictions Using E Team

Version

New Jersey State Police, Offi ffice of Emergency Management

Version 9.512

All All coun county ty-l -lev evel el eme emerg rgen ency cy man manag agem emen entt agen agenci cies es in in New New Jers Jersey ey

Versi ersion on 9 9.5 .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.x 3. x16

Nassau County Office of Emergency Management

Version 9.0217

12 Interview with Tom Tom Rafferty, Emergency Emergency Management Management Section of the New Jersey State Police. Police. 31 May 2012. The New Jersey State Police OEM is currently in the process of upgrading their E Team Team IMS to Version Version 9; the upgrade should be complete by summer 2012. 13 Interview with Tom Tom Rafferty, Emergency Emergency Management Management Section of the New Jersey State Police. Police. 31 May 2012. 14 Interview Intervi ew 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 Kenneth Davisdon, Dutchess Dutchess County Department Department of Emergency Response. 7 June 2012. 16 Interview with Ed Schneyer, Schneyer, Director of Emergency Preparedness Preparedness for Suffolk County Department of Fire, Rescue and Emergenc Emergency y Services. 7 June 2012. 17 Interview with John Bruckbauer, Bruckbauer, Nassau County OEM, 7 June 2012. OVERVIEW OF EXISTING SYSTEMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

9

KnowledgeCenter™ KnowledgeCenter™ is a web-based information management and communications tool developed by KnowledgeCenter™ Inc. and used by Pike County, PA. KnowledgeCenter™ KnowledgeCenter™ is built on a SQL database and is sold as an enterprise licensed solution. KnowledgeCenter’ KnowledgeCenter’s™ s™ database can be hosted by a third party or installed in a local data center. 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 ™

•

•

•

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” “Resources” module can support the more-advanced supply chain management (SCM) best-practices best-practices that would greatly assist responders in managing resources for a large-scale, multi-jurisdictional 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 Em Emergency Ma Management Ag Agency (P (PEMA)

Version 3. 3.9.219

Pike County (as part of the Northeast Pennsylvanian Regional Counter-Terrorism Counter-Terrorism Task Force, which whic h also includes i ncludes Carbon, Lackawanna, Lackawanna, Lehigh, Monroe, Northampton, Susquehanna, and Wayne Counties)

Version 3.9.220

18 Demonstration of KnowledgeCenter KnowledgeCenter ™ with John Gregory, Gregory, KnowledgeCenter™ KnowledgeCenter™ Inc. 26 May 2010. 2010. 19 Interview with Dave Williams, Williams, PEMA. June 2012. 20 Interview with Guy Miller, Monroe County County Office of Emergency Services. May 2012.

10

OVERVIEW OF EXISTING SYSTEMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

WebEOC® is a web-based collaboration-oriented WebEOC® 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.

WebEOC®

While resource requests are posted to an Incident Status Board for management of an individual incident, a Resources Resources Status Board enables users to manage an inventory of an agency’s resources.22 Although the standard installation of WebEOC® 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. solutions. These optional add-ons include GIS integration status boards 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 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 22 23 24 25

Interview with Jose DosSantos, FEMA Region 2. September September 2012. “WebEOC® Professional Version 7.” 7.” ESi®. Accessed from http://www.esi911.com http://www.esi911.com on 2 February 2010 “WebEOC® Resource Manager 2.0.” ESi®. Accessed from http://www.esi911.com http://www.esi911.com on 2 February 2010. http:/ ht tp://www.slideshare.net /www.slideshare.net /RIEMA/ WebEOC®-resource-ma WebEOC®-resource-manager nager accessed June 2012. Interview with John G. Gustafson, Emergency Telecommunications Telecommunications Manager for Connecticut Connecticut Department of Emergency Management and Homeland Security. Security. May 2012. 26 Interview with John G. Gustafson, Emergency Telecommunications Telecommunications Manager for Connecticut Connecticut Department of Emergency Management and Homeland Security. Security. May 2012. OVERVIEW OF EXISTING SYSTEMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

11

Information Sharing Mechanisms

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 conventional pathways that include in-person conversations, 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 coordinating resource requests among local, state and federal agencies using these conventional conventional pathways.

Current Request Process LOCAL

STATE

The incident command requests a resource via phone or phone 215. The EOC manually  or ICS Form 215. inputs requests into its tracking system and individually works with local partners to fill it.

FEDERAL

If the request cannot be filled locally, it is su bmitted phone,, e-mail e-mail,, and direct to the state EOC via phone coordination,, which works individually with state coordination resources, partners or EMAC to fill it.

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.

CURRENT PROCESS BEGINS

@

@ ARF

? !

INCIDENT

? !

STATE

215

RESPONSE

? LOCAL

!

EMAC

@

RESPONSE

FEDERAL RESPONSE

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 Katrina’s Katrina’s landfall, 27 FEMA received 864 unique Action Request Forms (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 NY-NJ-CT-PA Region, which is ho home me to 22 million people, pe ople, a 900% 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 incorporating information sharing capabilities within their IMSs. 27 Miguel Jaller and Jose Holguin-Veras. Holguin-Veras. “Immediate Resource Resource Requirements After Hurricane Katrina: Policy Implications for Disaster Response.” (Rensselaer Polytechnic Institute, 2010), 7. 7. 28 Federal Emergency Emergency Management Management Agency. “Agency Information Collection Collection Activities: Proposed Collection; Collectio n; Comment Request.” Request.” Federal Register. 69, no. 39 (2004): 9350.

12

INFORMATION SHARING MECHANISMS | CONFIDENTIAL. FOR OFFICI AL USE ONLY

•

• •

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. manually. Standards-based automation would allow emergency managers to: Streamline the resource request process process by automating the transmission transmission of data on requests, fulfillment and deployment. Reduce errors in resource requests by eliminating data-entry duplication. Boost visibility into resource 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 Region’s existing plans and procedures procedures are executed. The Region should look to interoperability interoperability as a way to expand the capabilities of its existing plans and procedures to efficiently manage resources resources in a catastrophe.

Proposed Request Process

PROPOSED PROCESS BEGINS

LOCAL

STATE

FEDERAL

The incident command electronically  requests electronically requests a resource with the EOC system, which shares information with local partners/syst partners/systems ems to fulfill it. Phones and ICS Form 215 can still be used.

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 m ay also be transmitted to an EMAC system.

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.

EOC SYSTEM

EOC SYSTEM

AR F

INCIDENT

EOC SYSTEM

EMAC MUTUAL AID

LOCAL RESPONSE OTHER LOCAL SYSTEMS

Connecticut

STATE

FEDERAL

RESPONSE

RESPONSE

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. web-porta l. Accordingly, information across all levels of government government in Connecticut can be managed through WebEOC’s® 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 Telecommunications Manager for Connecticut Department of Emergency Management and Homeland Security, May 2012. INFORMATION SHARING MECHANISMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

13

New Jersey

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 conventional pathways such as e-mail, phone and fax. NJ OEM is spearheading spear heading an effort ef fort to upgrade upgrad e the state’s version of E Team 2.4 to version 9.5, the latest release of the software from NC4™; the state’s 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 Jersey’s E Team easier and more reliable.

New York

Due to New York State’s 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 York State Division of Homeland Security Sec urity 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™ to-DisasterLAN™ messaging, or via interoperable standards such as EDXL-DE, EDXL-DE, and CAP. CAP. County OEMs that do not own own their own DisasterLAN™ can either use the State’s DisasterLAN™ web portal, email, or IPAWS-OPEN to convey information to the state. All DisasterLAN™ DisasterLAN ™ systems on version 8.0.5 8.0.5 and above, such as New York State and a nd Rockland County, can also communicate commu nicate over the t he IPAWS-OPEN IPAWS-OPEN 3.0 communication communicati on network using CAP, EDXL-DE, EDXL-DE, EDXL-RM, and CMAS.31 Dutchess County, New York City (NYC), Nassau, and Suffolk use different versions of E Team. Team. NC4’s™ latest release of E Team 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 Tom Rafferty, Emergency Emergency Management Section of the New Jersey State Police. 12 March 2010. 31 Interview with Patrick Patrick Cerra, Buffalo Buffalo Computer Graphics, Graphics, July 2012. 32 Interview with Erik Kant, NC4™. 20 May 2010. 2010.

14

INFORMATION SHARING MECHANISMS | CONFIDENTIAL. FOR OFFICI AL USE ONLY

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 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) (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 Implement ing 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, 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 interoperability 34 capabilities with other IMSs.

Pennsylvania

The eight county-level agencies of the Northeast Pennsylvania Counter Terrorism Task Force (NEPACRTTF), the Southeastern Southe astern Pennsylvania Pennsyl vania Regional Regi onal Task 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 ma nagement agencies within the Commonwealth. This capability will allow county-level 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. county-level. This transmission 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. reference.

33 Intervi ew with Mark Frankel, NYC NYC OEM June 2012. 34 Intervi ew with Tom Tom Lannon, Putnam County OEM. June 2012. INFORMATION SHARING MECHANISMS | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

15

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 agency’s agency’s existing plans and procedures. procedures.35

State-to-State (EMAC)

At present, each of the four state Emergency Management Associations (EMA) (EMA) in the Region uses a different IMS. As such, state-to-state Emergency 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 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 Region’s IMSs.36

Federal

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, electronic ally, 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 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® 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 FEMA’s Logistics and Supply Chain Management System (LSCMS) is another resource management system modeled on 3PL and SCM best-practices best-practices that is used to fulfill orders and track resource requests, shipments and receipts. Once released, FEMA’s LSCMS should boost the agency’s 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 County PA OEM, and Dave Williams, PEMA. June 2012. 36 Interview with Captain Howard Howard Butt, EMAC State Coordinator for for New Jersey State Police. Police. 24 March 2010. 2010. 37 Miguel Jaller and Jose Holguin-Veras. Holguin-Veras. “Immediate Resource Resource Requirements Requirements After Hurricane Katrina: Policy Implications for Disaster Response.” Response.” (Rensselaer Polytechnic Polytechnic Institute, 2010). 38 Interview with Jason Wind, FEMA Region II. 20 June, 2012. 2012. 39 Interview with Jason Wind, FEMA Region II. 20 June, 2012. 2012.

16

INFORMATION SHARING MECHANISMS | CONFIDENTIAL. FOR OFFICI AL 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. Common Alerting Protocol (CAP)

All of the Region’s incident management systems support some degree of standardsbased 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: •

•

•

•

•

•

•

Emergency Data Exchange Language Distribution Element (EDXL-DE)

•

• • • • • •

•

Interoperability: The CAP Alert Message should provide a means for interoperable exchange exchange of alerts and notifications among all emergency information systems. 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 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:// http://docs.oasis-op docs.oas is-open.org en.org /emergency/cap/v1.2/CAP-v1.2-o emergency/cap/v1.2/CAP-v1.2-o s.html. Accessed 7 June, 2012. 41 http://www.oasis-open.org http://www.oasis-open.org /committees/ committe es/download. download.php/17227/EDXL-DE_Spec_v1.0.ht php/17227/EDXL-DE_Spec_v1.0.html. ml. Accessed on 7 June 2012. INFORMATION SHARING CAPABILITIES | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

17

Use of Established Standards

Each IMS approaches interoperable messaging standards differently. differently. The following table summarizes existing standards-based information sharing capabilities currently observed in the Region.

Information Sharing Capabilities Native Data Format

SQL Other

Casting

Pushes data automatically or at set intervals Transmits CAP messages Wraps data in EDXL-DE standard Can send any current EDXL Standard (Excluding CAP) Can send via non-EDXL non-EDXL NIEM compliant Standard Can send Commercial Mobile Alert System (CMAS) messages

Routing

Transform data based on user-defined principles Routes messages based on EDXL-DE standard Can route via non-EDXL NIEM compliant Standard Routes messages based on publish / subscribe Utilizes an enterprise service bus (ESB)

Receiving

Pulls data automatically / at set intervals Receives CAP messages Receives EDXL-DE messages Receives any current EDXL Standard (Excluding CAP) Can receive via non-EDXL NIEM compliant Standard (Excluding CAP)

General

Customizable Customizable reports Adapters for legacy systems User-interface User-interface to present shared / aggregated data Minimal impact to existing plans / processes Role-based data-sharing and security model

18

INFORMATION SHARING CAPABILITIES | CONFIDENTIAL. FOR OFFICI AL USE ONLY

DisasterLAN™

E Team

x

KnowledgeCenter ™

WebEOC®

x

x

x (Server Agnostic) x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

N/A

x

N/A

x

x

x

x

x

x

x

x

x

x

x

x

x

INFORMATION SHARING CAPABILITIES OVERVIEW | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

19

Adopting EDXL EDXL-RM -RM

The Emergency Data Exchange Language – Resource Messaging (EDXL-RM) (EDXL -RM) is a recognized messaging standard st andard that can support the Region’s 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 resource request linking and field asset visibility.

EDXL-RM Background and Overview

• •

•

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 Interoperability and Compatibility (OIC) (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 EDXL-RM has also been registered and accepted as a National Information Exchange Exchange Model (NIEM) 2.0 Conformant Conformant Schema, making it the only publicly published data-sharing standard available to projects that require NIEM-compliance. 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 NIEM-conforma nt standard, EDXL-RM appears to be the only recognized standard for emergency management resource 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 Technical Overview

• • •

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 Team Meeting Minutes, June 2010. 43 “B2-15 National Information Exchange Model (NIEM).” (NIEM).” Department of Homeland Homeland Security. Acquisition Instruction / Guidebook #102-01-001: Interim Version Version 1.9, Appendix B, November 2008. 44 Grant Recipient IEPD Registration Registration Requirements. NIEM Program Management Management Office. NIEM Implementation Guidelines. Guidel ines. 9 June 2010. Accessed on 10 June 2010 from http://www.niem.gov/implementati http://www.niem.gov/implementationguid onguide.php. e.php.

20

ADOPTING EDXL-RM | CONFIDENTIAL. FOR OFFICI AL USE ONLY

• •

• • •

•

•

•

•

The EDXL-RM standard message enables information sharing between resource consumers and resource 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, 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. VOADs. Requests for Resources, such as formally procuring a generator from a state agency. Requisitions for Resources , for eventual linkages to agency procurement 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 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 agency or private vendor for delivery of a resource resource to an incident location or staging area. Requests to Extend Deployment Duration, such as requests to continue renting a resource resource from a private vendor when a need exists. These messages are standardized standardized into 16 different schema, or standard message templates for data-sharing. The following figure figure shows the different message behaviors under EDXL-RM. Request Information Response to Request Information

Discovery

RESOURCE CONSUMER

Request Quote Response to Request Quote

RESOURCE SUPPLIER

Offer Unsolicited Resource

Request Resource

Ordering

RESOURCE CONSUMER

Response to Request Resource Requisition Resource

RESOURCE SUPPLIER

Commit Resource

Request Return Response to Request Return Request Resource Deployment Status

Deployment

RESOURCE CONSUMER

Report Resource Deployment Status Release Resource

RESOURCE SUPPLIER

Request Extended Deployment Duration Response to Request Extended Deployment Duration ADOPTING EDXL-RM | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

21

Implementing Implement ing EDXL-RM EDXL-RM in the Region

This section examines possibilities for the t he Region’s IMSs to become compliant to the EDXL EDXL-RM -RM standard and how EDXL-RM EDXL-RM messages can be shared between jurisdictions. All the IMSs in the Region currently provide provide a method for interoperable data sharing that supports resource management and corresponding operational coordination. However, interoperability 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 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 resource requests and status. The table below lists the tools and capabilities needed for each IMS to support resource resource management. Further details and sources are included on the following page.

Capabilities to Support Resource Management Among IMSs Ordering / Acquiring Resources

Forward a resource order or request to a local, state, or federal management information system in a manner that supports pre-established resource resource ordering and request procedures.

Mobilizing Resources

Notify resource providers / suppliers of mobilization, automatically providing: •

Date, time and place of departure (if applicable)

•

Mode of transportation to the incident (if applicable)

•

Estimated date and time of arrival

•

Reporting location (address), contact name and information

•

Resource Resource ordering numbers (if applicable)

•

Incident numbers (if applicable)

•

Cost and funding codes

Support on-scene check-in processes of resources that have arrived at the incident, including validation of order requirements and automatic notifications that resources have arrived. Reference Reference mobilization and demobilization information. Tracking, Inventorying I nventorying and Reporting Resources

Track resources continuously and automatically from mobilization to demobilization. Alert on-site personnel at the incident to prepare for incoming resources. Assess the availability of assets in a jurisdiction’s inventory, inventory, as well as those that can be provided by a cooperating jurisdiction. Automate reimbursement documentation requirements for resources used at an incident.

Reimbursement for Resources

22

Validate and generate reimbursement claims for the proper authorities.

IMPLEMENTING EDXL-RM IN THE REGION | CONFIDENTIAL. FOR OFFICIAL USE ONLY

DisasterLAN™

E Team

KnowledgeCenter ™

WebEOC®

x

x

x

x

N/A

N/A

N/A

N/A

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

IMPLEMENTING EDXL-RM IN THE REGION | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

23

While each IMS has similar basic capabilities for operational coordination, they all have different means of supporting interoperability interoperability.. In addition, each IMS supports the EDXL-RM EDXL-RM standard standa rd in its own way. way. E Team Team and DisasterLAN™ can maintain a database of suppliers (both public and private) to assist users in fulfilling fulfill ing resource requests. WebEOC’s® version 7 Professional Professional comes with a standard “Resources” status board, which helps users maintain, manage, and assign inventory of available resources. KnowledgeCenter’s resource management module is fully EDXL-RM capable and provides full interoperable messaging capabilities using the EDXL-RM standard through a web services applications programming interface (API). This allows resource resource consumers and providers to directly interface with the IMS, streamlining resource management plans and procedures. DisasterLAN™ has developed an interoperable message module that can share EDXLRM messages. This module has already been used to send and receive messages using both the Common Commo n Alerting Protocol (CAP) and EDXL-DE.45 The DisasterLAN™ interoperability interoperability module has also begun to introduce capabilities to send resource resource requests between different DisasterLAN™ users. ETeam’s version 9 offers custom forms through its Web Services architecture that enable users to customize the format of a resource message so that requests and responses are compatible with different IMSs on the receiving end of a message.46 These custom forms can be structured to conform to the EDXL-RM standard by providing an adapter to translate the IMS’s internal messages into a format that could be read by other EDXL-RM compatible systems. NYC OEM has successfully exported a resource request report from ETeam, wrapped it in EDXL-DE, and posted it to IPAWS. IPAWS. The next steps are to convert conver t the standard resource reso urce request into a valid vali d 47 EDXL-RM message. ESi offers an optional add-on, ESi WebFUSION, which allows WebEOC® users to communicate with older olde r versions of WebEOC WebEOC servers. The product may be able to support nearly any type of IMS through the use of adapters or controllers that can be plugged into the product.48 ESI WebFusion, which functions as a message server using a publish-subscribe model, provides capabilities that could support connections to several different IMSs.

45 “DisasterLAN™ “Disast erLAN™ Interoperable Messaging Module.” B CG. Accessed Acce ssed from http://www. http://www. buffalocomputergraphics.com/ buffalocomputergraphics.com/documents/interoper documents/interoperable-messaging.pdf able-messaging.pdf on 2 April 2010. 46 Interview with Erik Kant, NC4™. 20 May 2010. 47 Interview with Mark Frankel, Frankel, NYC OEM, June 2012. 48 “ESiWebFusion.” ESi®. Accessed from http://www.esi911.com http://www.esi911.com on 2 February February 2010.

24

IMPLEMENTING EDXL-RM IN THE REGION | CONFIDENTIAL. FOR OFFICIAL USE ONLY

Establishing Regional Operational Coordination

Once the Region’s IMSs are able to use EDXL EDXL-RM -RM as a standardized means for interoperable data sharing that supports resource management between jurisdictions, it is necessary to explore a method for routing these EDXL-RM standardized resources resources messages from one IMS to another.

•

•

The RIMS Planning Team explored two federally-developed linkages that are available to the Region at no-cost. These include: IPAWS-OPEN (Integrated Public Alert and Warning System – Open Platform for Emergency Networks) – an interoperability initiative under development by FEMA’s Disaster Management Program and the Integrated Public Alert and Warning System Division for the emergency management community. UICDS (Unified Incident Command for Decision Support) – an interoperability interoperability initiative under development by DHS Science and Technology Directorate for the broader homeland security community. Commercial-off-the shelf solutions (COTS) were also researched and considered prior to the Planning Pla nning Team’s Team’s decision; descripti d escriptions ons of the COTS and other nonstandards based solutions can be found in Appendix A.

Integrated Public Alert and Warning System – Open Platform for Emergency Network (IPAWSOPEN)49

The Integrated Public Alert and Warning System – Open Platform for Emergency Networks (IPAWS-OPEN) (IPAWS-OPEN) was originally origina lly developed develop ed as part of FEMA’s FEMA’s Disaster Management program to support information-sharing. IPAWS is an integrated set of services and capabilities that enable local, state, and federal authorities to alert and warn their communities of a hazard. As of 2011, commercial radio broadcast stations partnering with FEMA on public information and warning served 84 percent of the U.S. population, populat ion, up from approximately app roximately 67 percent in 2009. 20 09. As part of the IPA IPAWS WS programs, programs, these broadcast stations are equipped with backup communications equipment and power generators to continue to support broadcasting prior to, during, and after an event.50 IPAWS-OPEN functions as middleware, or a third-party, that connects two agencies when they communicate with one another. It provides a way for emergency responders in the field, operations centers, and across all levels of government government to share information in real-time across different software programs, systems, networks and devices, utilizing the following EDXL standards:51

49 Reviewed Reviewed and approved by Neil Graves, IPAWS IPAWS Engineering Branch. 18 June 2012. 50 FEMA National Preparedness Prepared ness Report May 3, 2012 https://www.fema.gov https://www.fema.gov/librar /library/ y/viewRecord. viewRecord. do?id=5914 51 FEMA. DM-OPEN DM -OPEN Full Requirements. Requirement s. 19 February 2009. ESTABLISHING REGIONAL OPERATIONAL COORDINATION | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

25

•

•

•

CAP: Common Alerting Protocol – a message format for emergency alerts and warnings that can be universally accepted by a variety of networks and devices.52 NWEM: Non-Weather Emergency Messages – a distribution format in use by the National Weather Service (NWS) and the Emergency Alert System (EAS).53 EDXL-DE: a standard envelope or “wrapper” for other emergency messages that can facilitate routing of its contents to recipients using information such as distribution type, geography, incident and sender/recipient.54 In theory, if IPAWS-OPEN IPAWS-OPEN were implemented implemen ted in each agency’s agenc y’s IMS there should be no impact to user operation within an agency’s existing plans and procedures, procedures, since all data-sharing activities would occur in the background while users continue their normal system use. This could allow agencies to quickly adopt the system without any required changes to the way in which their personnel currently operate. All of the Region’s IMSs appear fully engaged with IPAWS-OPEN so it is likely that information sharing capabilities within upcoming versions of the Region’s Region’s IMSs will closely mirror those capabilities supported by IPAWS-OPEN. Like a courier service, ser vice, IPAWS-OPEN IPAWS-OPEN will not read or o r validate the th e EDXL-RM content contained within the envelope. envelope. Just as individuals receive mail that may or may not be “junk” mail, IPAWS-OPEN will not be able to use EDXL-RM to discern applicability based on message content. content . If EDXL-RM messages are to be effective using IPAWSIPAWSOPEN, an agency’s IMS will need to interpret these messages appropriately, which they currently cannot do. Since IPA IPAWS-OPEN will rely upon distribution “groups” called Collaborative Operations Groups, or COGs, it is also unclear if IPAWS-OPEN will fully utilize the routing capabilities inherent in the EDXL-DE structure, structure, which can enable distribution capabilities based on a variety of parameters such as agency-type, specific incidents, geography, or specific senders/recipients. Some questions remain on whether IPAWS is capable of managing the scale of traffic that would be required requi red after a catastrophe. ca tastrophe. However, since IPAWS-OPEN IPAWS-OPEN is a free tool under development by FEMA, based on publicly available standards, and requires no new hardware to use, the platform will likely win considerable credibility among agencies seeking to improve their data-sharing abilities. Despite these questions, IPAWS-OPEN presents a promising potential interoperability interoperability platform for the Region, and represents a solid first step in a path forward that will lead to greater interoperability interoperability among the many agencies across the Region.

52 OASIS. Common Alerting Protocol, Protocol, v. v. 1.1: Oasis Standard CAP-V1.1, CAP-V1.1, October October 2005. Accessed on 22 February 2010 from http://www.oasis-open.org http://www.oasis-open.org /committees/ committee s/download. download.php/15135/emergencyphp/15135/emergencyCAPv1.1-Corrected_DOM.pdf 53 FEMA Disaster Management Program Program – Open Platform for Emergency Emergency Networks. Instructions for Using the NOAA HazCollect Interface Interface on the Open Platform for Emergency Networks (OPEN). 6 Nov 2008. Accessed on 28 February 2010 from http://www.oasis-open.org http://www.oasis-open.org /committees/ committee s/download. download.php/3108 php/31085/ 5/ using_hazcollect_on_open20081106.pdf 54 OASIS. Emergency Data Exchange Exchange Language Distribution Element, Element, v. 10.: OASIS Standard EDXL-DE EDXL-DE v1.0, v1.0, 1 May 2006. Accessed on 22 February 2010 from http:// http://docs.oasis-ope docs.oas is-open.org n.org/ /emergency/edxl-d emergency/edxl-de/v1.0/ e/v1.0/ EDXL-DE_Spec_v1.0.pdf

26

ESTABLISHING REGIONAL OPERATIONAL COORDINATION | CONFIDENTIAL. FOR OFFICIAL USE ONLY

Unified Incident Command and Decision Support (UICDS)

UICDS is a framework framework currently under development by the Infrastructure and Geophysical Division of the DHS Science and Technology Directorate. The framework will be freely available and is designed to have no impact on how users operate their existing IMS.55 Under the UICDS framework, a IMS would send resource messages to components of this framework, described as a UICDS “core.” “core.” Rather than routing information, the UICDS core would “publish” their data to other IMSs that have subscribed themselves to receive messages from the UICDS core.56 By using this model of data distribution, the framework resembles a collection of these cores, similar in structure to a peerto-peer network. UICDS cores would likely likely be hosted on local servers maintained by agencies who are utilizing the framework. UICDS contains a “Resource Providers Core,” serving as an EDXL-RM-based platform that would unite disparate public and private systems to manage resources using existing inventory, inventory, personnel and supply chain tools. Such a platform could have potential for enabling resource resource data-sharing. UICDS is also engaged with vendors of IMS products through a Technology Providers program, ensuring that vendors of products such as the Region’s IMSs are engaged in the platform’s development. development. Although both ESi and NC4™ have downloaded the development kit from the UICDS Region’s vendors will commit to releasing site,57 it is not yet clear when any of the Region’s versions of their IMSs that will fully-support UICDS standards and requirements for the “Resource Providers Core,” which is based substantially on the EDXL-RM standard. The use of locally-owned hardware for UICDS core servers, while minimal as a requirement, requirement, will also make implementation more complex. Agencies wishing to connect to multiple cores may find it difficult to interface with the framework framework effectively, effectively, and diversity in information security policies among many of the Region’s Region’s agencies will likely present a challenge to early adopters. Another potential challenge for UICDS revolves around uncertainty as to whether vendors will be willing to develop adapters adapters for their software products. products. While some agencies might be able to develop their own adapters to side-step this cost, such actions might be blocked through license agreements with vendors and contracts for technical support assistance. In addition, although UICDS has adopted the NIEM standards, the scope of the UICDS program, which is far broader than IPAWS-OPEN, will likely find integration of data from different sources and in different formats a challenging task to overcome. overcome. To mediate this, UICDS will ultimately need to provide strong guidance on data standards, a task which might present a challenge when dealing with the legacy software that might be used to manage older government-sector government-sector data systems. 55 “UICDS in Brief.” [PowerPoint Presentation.] Presentatio n.] Accessed on 4 March 2010 from http://www http://www.uicds .uicds.us. .us. 56 “UICDS Overview for Technolog Technology y Providers.” Accessed on 4 March 2010 from http://www http://www.uicds .uicds.us. .us. 57 E-mail from Chip Maloney, Maloney, Principle Systems Engineer. Engineer. 24 November November 2009. ESTABLISHING REGIONAL OPERATIONAL COORDINATION | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

27

Appendix A

NIMSSupporting Technology Evaluation Project (STEP)

The Federal Emergency Management Agency (FEMA) National Preparedness Directorate (NPD) offers the t he Supporting Support ing Technology Technology Evaluation Project (STEP) to assist the response community with w ith evaluation and testing of IMSs. This project evaluates evaluates and verifies interoperability of commercial and government software and hardware. Each IMS is evaluated to determine incorporation of: of : • • • • • •

NIMS-STEP Evaluations

NIMS concepts and principals Common Alerting Alertin g Protocol (CAP) version 1.1 and 1.2 Integrated Public Publ ic Alert Warning System (IP (I PAWS) AWS) version 1.0 Emergency Date Exchange Language- Distribution Element (EDXL-DE) Emergency Date Exchange Language- Hospital Availability Exchange (EDXL-HAVE) Emergency Date Exchange Language- Resource Messaging (EDXL-RM)58 DisasterLAN™ is the only system in use in the Region to have been evaluated by NIMS-STEP. The National Incident Management System Supporting Technology Evaluation Program (NIMS STEP) has determined that DisasterLAN™ incorporates all 24 of the NIMS concepts and principals. These 24 principals fall under the categories of Emergency Support, Hazards, Preparedness, Communications and Information Management, Resource Management and Command and Management. NIMS STEP found that DisasterLAN™ implements all of the mandatory EDXL-DE EDXL-DE elements and 59 easily generates CAP compliant alert messages. E Team, Team, KnowledgeCenter™ KnowledgeCen ter™ and WebEOC® were not submitted for NIMS-STEP evaluation. NIMS-STEP evaluates a product’s successful incorporation of EDXL-RM, an existing standard that is available but not widely implemented. An easy way for the Region to establish the core capability brought forth by NIMS and the National Preparedness Goal is through the adoption of EDXL-RM as its standard.

58 STEP Home.” FEMA. Accessed on June 7th, 2012 from https:/ https: //www.ptaccent /www.ptaccenter.org/step/index er.org/step/index 59 Results from each evaluation evaluation may be accessed at www.rkb.us (keyword (keyword STEP). Accessed June 2012

28

APPENDICES | CONFIDENTIAL. FOR OFFICIAL USE ONLY

Appendix B

Additional Research

HIPPOCRATES

Commercial off the shelf (COTS) (COTS) solutions that serve s erve as platforms for routing EDXL-RM standardized resources messages from one IMS to another were researched in addition to the government solutions. These platforms were considered for implementation within the Region: HIPPOCRATES is a tool developed by the New Jersey Department of Health and Senior Services (NJ DHSS). Like other interoperability platforms, HIPPOCRATES functions as a middleware middleware platform to integrate data from different healthcare sources through through a portal that can function as a IMS with an advanced GIS display. display. HIPPOCRATES is an impressive platform for managing health-care incidents while providing a common operating picture picture for state-level healthcare managers. managers. While these capabilities can be applied to emergency management, several prime areas of development would be necessary for the platform to be as valuable in emergency management as it has been for its healthcare healthcare constituents. Such areas include interoperability, interoperability, standards-adoption, standards-adoption, and data capabilities to support resource resource management / supply chain functionality. HIPPOCRATES HIPPOCRATES is the only public solution researched for this paper that has considered the continuing proliferation proliferation of mobile devices and their potential to serve as effective data access-points for emergency response response personnel. As a IMS, HIPPOCRATES HIPPOCRATES has the ability to send data to mobile devices, though this ability has so far been limited to basic surveys for situational awareness. awareness. https ://hipp /hippocrates.n ocrates.nj.gov/ j.gov/ Additional information on the platform is available at https:/

FATPOT: FATPOT: For all the People of the (World)

FATPOT FATPOT Peer Peer Intelligence Intel ligence Virtual Data Da ta Fusion Software is a commercial commerci al off-the-shelf off-the-s helf middleware platform. The system is unique because it does d oes not require existing IMSs to use a standard such as EDXL-RM for data-sharing messages and would therefore not require the Region to adopt adopt any one standard. Since there are at least four IMSs in use by the Region, this would greatly simplify the Region’s path-forward for improved data-sharing. data-sha ring. In theory, theor y, if FA FATPOT were implemented in each eac h agency’s IMS there should be no impact to user operation because all data-sharing activities would occur in the background while users continue their normal system use. Unlike the public systems evaluated in this paper, paper, the tool is for sale by a private vendor. In addition, FATPOT FATPOT would only integrate the current c urrent versions of the t he Region’s IMSs. As such, if agencies upgrade or change their IMSs, they would also need to upgrade the FATPOT FATPOT platform to ensure that it continues co ntinues to pass these th ese messages. FATPOT FATPOT would be implemented implemente d with a centralized h hub ub and spoke structure, struct ure, where all messages are first sent to a central server where they are routed to the intended recipient. recipien t. FATPOT’s FATPOT’s centralized platform platf orm can provide users with access to a virtual virtua l view of the Region’s resources. Unlike a courier service, which would analyze only information inform ation on the message’s messa ge’s envelope, the FATPOT FATPOT system would analyze APPENDICES | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

29

information within the message itself and translate it for the intended recipient’s IMS, using adapters, data mapping tables and data transformation services.60 FATPOT FATPOT states that it can work as a data-sharing dat a-sharing platform, p latform, regardless regard less of system or 61 vendor.  While all the other solutions require additional development and testing before they are functional, FATPOT has demonstrated its ability to link different IMS and CAD systems. However, of the four IMSs in our Region, the only on ly IMS that FATPOT FATPOT 62 has specifically integrated is WebEOC®. http: //www.fatpot /www.fatpot.com .com Additional information on the platform is available at http:/

Thinkstream

Thinkstream Thinkstream differs from other middleware middleware platforms in its focus on industry standards such as EDXL-RM for data-sharing messages, with tools to translate information with systems that may not be compliant with such standards. Thinkstream’s incorporation of a common standard such as EDXL-RM ensure that the system can be crafted to be NIEM-conformant. Thinkstream Thinkstream is implemented using either an Enterprise Server Bus (ESB) or a Service Oriented Architecture Architecture (SOA) model. Either solution provides robust data mapping and transformation tools, which can bridge different information structures into a common network-wide XML schema which might be customizable to the Region, or standardized in a structure compliant with NIEM such as EDXL-RM. Such a strategy should enable the platform to function independent of perpetual IMS upgrades, so long as the standard chosen by the Region remained consistent. Like FATPOT FATPOT,, Thinkstream is for sale sal e by a private vendor; vend or; as such, the financial f inancial implications of selecting this tool may differ from other freely-available freely-available middleware options such su ch as IPAWS-OPEN IPAWS-OPEN and UICDS. UI CDS. However, However, while FATPOT FATPOT would only integrate the current versions of the Region’s IMSs, Thinkstream has worked with several emergency management projects in California to provide continuing interoperability interoperability between systems, despite upgrades that might alter internal datahandling procedures. procedures. Additional information on the platform is available at http:/ http: //www.thinks /www.thinkstream.com tream.com

60 FATPOT FATPOT Technolog Technologies ies LLC. “FATPOT “FATPOT Peer Intelligence Intelli gence – Virtual Data Fusion Software: An Interoperable Platform for Public Safety.” 15 August 2007. 61 FATPOT FATPOT Technologies echnolog ies LLC. Promotional Promotiona l Literature: “Public Safety and Homeland Security Data Interoperability.” Interoperability.” Received at the 2nd Annual State Border Coordination Workshop, Workshop, Gettysburg, PA. PA. 26 January 2010. 62 Telephone call with wit h Scott LeFevre of FATPOT FATPOT Technologies echnolog ies LLC. 11 January 2010.

30

APPENDICES | CONFIDENTIAL. FOR OFFICIAL USE ONLY

Other Solutions • • • • • • • • • • • •

Other systems that have been researched, but which do not appear to provide capabilities to specifically support regional interoperability of resource management activities include: UAI 1-Link – Comprehensive Comprehensive enterprise platform Depiction – Real-time simulation and collaboration collaboration tool EmerGeo FusionPoint – Web-based information management system HSIN – Homeland Security Information Network Mule ESB – Open Source Enterprise Server Bus SAHANA – Open Source Disaster Management System SBEOCS – Strategic Biodefense Emergency Operations Communications Systems SUMA – Humanitarian Supply Management Systems VidSys – Physical Security Information Management Software WorkCenter by VirtualAgility VIPER – Virginia Interoperability Picture for Emergency Response Virtual Alabama / vUSA

APPENDICES | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

31

Appendix C

This section provides information on how to find additional information on issues discussed discus sed in this paper. Supporting Information for EDXL-RM

OASIS Emergency Management Technical Committee http://www.OASIS-open.org/committees/emergency/ Emergency Data Exchange Language – Resource Messaging 1.0 (EDXL-RM 1.0 Os) OASIS Standard Incorporating Incorporating Draft Errata (21 July 2009) http:/ http: //docs.OASIS-open.or docs.OASIS -open.org/emergency/EDXL-RM/v1.0 g/emergency/EDXL-RM/v1.0/ /os/EDXL-RM Disaster Management Interoperablity Services (FEMA) Standards and Initiatives http://www.disasterhelp.gov/disastermanagement/open/standards.shtm NIEM-Related Technical Information Related to EDXL http://NIEM.gov/NIEM/EDXL/2.0/ NIEM Implementation Guidelines http://www.NIEM.gov/implementationguide.php

Supporting Information for IPAWS

Disaster Management Program Standards: Interoperable Data Exchange http://www.FEMA.gov/about/programs/disastermanagement/standards/index.shtm OPEN Web Interoperability Services http://www.FEMA.gov/about/programs/disastermanagement/open/services.shtm OASIS Emergency Management Technical Committee http://www.OASIS-open.org/committees/emergency/ DM-OPEN Web Services http://www.FEMA.gov/about/programs/disastermanagement/open/index.shtm DM-OPEN Web Services Special Interest Group Information http://www.FEMA.gov/about/programs/disastermanagement/open/sig.shtm FEMA - Integrated Public Alert and Warning System System Division Projects http://www.FEMA.gov/emergency/ipaws/projects.shtm#6

Supporting Information for UICDS

32

UICDS: Unified Incident Command for Decision Support http://www.uicds.us

APPENDICES | CONFIDENTIAL. FOR OFFICIAL USE ONLY

References

Glossary

Application Programming Interface (API): An open-standard method of sharing information that can be programmed onto an existing database with internet capability. capability. It enables data sharing between systems by authenticating user access with the database system and presenting the information. Common Alerting Protocol (CAP): An XML-based data format used to deliver consistent emergency alert messages simultaneously over different systems.

communication that does not rely on electronic Conventional Pathway: A mode of communication data interchange (EDI) for sharing of information. These conventional conventional pathways include: e-mail, facsimiles, paper documents, and spoken conversation over radio, phone, or in-person. Incident Management System (IMS): Software that provides emergency management agencies with a common platform from which they can enhance their ability to respond to and recover from incidents and events occurring within their jurisdiction. It provides users a common operating picture and resource management tool through a single collaboration platform. Emergency Data Exchange Language – Distribution Element (EDXL-DE): (EDXL-DE): A standard message distribution framework framework that serves as a container to route properly formatted XML messages. The EDXL-DE wraps the message and contains key routing information information such as the name and address of the recipient and the sender. Emergency Data Exchange Language Resource Messaging (EDXL-RM): A suite of standard messages for sharing data among information systems that coordinate requests for emergency equipment, supplies, and people. Enterprise Service Bus (ESB): A database architecture that allows for standardize messages to travel between mutually interacting software applications. applications . ESBs allow for a modular deployment of interfaces that can seamlessly interact within a single networked database system. Interoperability: The ability for different systems to talk to each other and achieve resource resource visibility among different jurisdictions. National Incident Management System (NIMS):  Provides a systematic, proactive approach to guide departments and agencies at all levels of government, nongovernmental nongovernmental organizations, organizations, and the private sector to work seamlessly to prevent, protect against, respond to, recover recover from, and mitigate the effects of incidents, regardless of cause, size, location, or complexity, in order to reduce the loss of life and property and harm to the environment. National Incident Management System Supporting Technology Evaluation Program (NIMS-STEP): This project evaluates and verifies interoperability of commercial and government software and hardware including Information Management Systems (IMSs). REFERENCES | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

33

Schema: Standardized message formats for data sharing through XML. SQL (Sequel): A special purpose programming programming language designed for managing managing data in relational database management systems. Universal Logistics Standard: A foundation on which local, state, and federal stakeholder can build a comprehensive disaster logistics program

34

REFERENCES | CONFIDENTIAL. FOR OFFICIAL USE ONLY

Acronyms

Acronym

Definition

3PL

Third-Party Logistics

API

Application Programming Programming Interface

ARDEC

Armament Research Development and Engineering Center

ARF

Action Request Form

BCG

Buffalo Computer Graphics

CAD

Computer-Aided Dispatch

CAP

Common Alerting Alertin g Protocol

COG

Collaborative Operations Group

CONOPS

Concept of Operations

COTS COTS

Commercial Off-The-Shelf Solution

CMAS

Commercial Commercial Mobile Alert System

CT DEMHS

Connecticut Connecticut Department of Emergency Management and Homeland Security

DHS

Department of Homeland Security

DM-PSG

Disaster Management – Practitioner Practitioner Steering Group

EAS

Emergency Alert System

EDI

Electronic Data Interchange Interchange

EDXL

Emergency Data Exchange Language

EDXL-DE

Emergency Data Exchange Language – Distribution Distribu tion Element

EDXL-HAVE EDXL-HAVE

Emergency Data Exchange Language – Hospital Availability Exchange

EDXL-RM

Emergency Data Exchange Language – Resource Messaging

EMA

Emergency Management Agency

EMAC

Emergency Management Assistance Compact

EMS

Emergency Medical Services

EOC

Emergency Operations Center

ESB

Enterprise Service Bus

ETL

Extract, Transform, Load

FATPOT FATPOT

For All The People Of The ("World")

FEMA

Federal Emergency Management Agency

GIS

Geographic Information System

IMS

Incident Management System

IPAWS IPAWS

Integrated Public Alert and Warning System

IPAWS-OPEN IPAWS-OPEN

Integrated Public Alert and Warning System –Open Platform for Emergency Networks

ICS

Incident Command System

REFERENCES | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

35

36

IT

Information Informati on Technology

LAN

Local Area Network

LSCMS

Logistics Supply Chain Management System

NEMA

National Emergency Management Association

NEPARCTTF

Northeast Northeas t Pennsylvania Regional Counter Terrorism Task Force

NIEM

National Information Exchange Model

NIMS

National Incident Management System

NIMS-STEP

NIMS Supporting Supporti ng Technology Evaluation Program

NJ DHSS

New Jersey Department of Health and Senior Services

NJ OEM

New Jersey Office of Emergency Management, New Jersey State Police

NPD

National Preparedness Directorate

NWEM

Non-Weather Non-Weather Emergency Messages

NWS

National Weather Service

NYC OCME

New York City Office of Chief Medical Examiner

NYC OEM

New York City Office of Emergency Management

NYS DH DHSES

New York St State Di Division of Ho Homeland Se Security an and Em Emergency Services

OASIS

Organization Organizatio n for the Advancement of Structured information informatio n Standards

OCME

Office of Chief Medical Examiner

OEM

Office of Emergency Management

OIC

Office of Interoperability Interoperability and Compatibility

PEMA

Pennsylvania Emergency Management Agency

RCPGP

Regional Catastrophic Catastrophi c Preparedness Grant Program

RCPT

Regional Catastrophic Catastrophi c Planning Team

RIC

Regional Integration Center

RIMS

Regional Information Management Solution

ROIC

Regional Operations Integration Center

RRMS

Regional Resource Management System

SCM

Supply Chain Management

SEPARTF

Southeastern Southeaste rn Pennsylvania Regional Task Force

SOA

Service Oriented Architecture

SQL

Structured Query Language

UICDS

Unified Incident Command and Decision Support

VOAD

Voluntary Organizations Active in Disaster

XML

Extensible Markup Language

REFERENCES | CONFIDENTIAL. FOR OFFICIAL USE ONLY

Bibliography Bruckbauer, John. Nassau County Office of Emergency Management. Interview June 2012. Buffalo Computer Graphics. “DisasterLAN Call Ticket Manager.” Accessed May 16, 2012. http:// http://www.buffalocomputergraphics.co www.buffalocomput ergraphics.com/ m/documents documents/DLAN%20Cal /DLAN%20Call%20Center%2 l%20Center%20 0 Slick.pdf Buffalo Computer Graphics. “DisasterLAN Interoperability Messaging Module.” Accessed May 16, 2012. http:// http://www.buffalocomputergraphics.co www.buffalocomput ergraphics.com/ m/documents/i documents/interoperable nteroperable-messaging.pdf Buffalo Computer Graphics. “DisasterLAN Preplanning Module.” Accessed May 16, 2012. http:// http://www.buffalocomputergraphics.co www.buffalocomput ergraphics.com/ m/documents documents/DLAN%20Prepl /DLAN%20Preplanning%20 anning%20 Slick.pdf Butt, Captain Howard. New Jersey State Police. Interview March 24, 2010. Cerra, Patrick. Buffalo Computer Graphics. Interview July, 2012. Department of Homeland Security. “B2-15 “B2-15 National Information Exchange Model (NIEM).” Acquisition Instruction / Guidebook #102-01-001: Interim Version 1.9, Appendix B, November 2008. Davidson, Kenneth. Dutchess County Office of Emergency Response. June 7, 2012. ESi®. “WebEOC® Professional Professio nal Version 7.” 7.” Accessed February, 2010. http:/ http: //www.esi911. /www.esi911. com. ESi®. “WebEOC® Resource Manager. M anager.”” Accessed February, 2010. http:// http://www.esi911.com. ESi®. “ESi® “E Si® WebFusion.” Accessed February, 2010. 20 10. http:// http://www.esi911.com. FATPOT FATPOT Technologi Technologies, es, LLC. “FATPOT “FATPOT Peer Intelligence – Virtual Data Fusion Software: An Interoperable Interoperabl e Platform for Public Publ ic Safety.” August 15, 2007. 2007. FATPOT FATPOT Technologi Technologies, es, LLC. “Public Safety S afety and Homeland H omeland Security Se curity Data Interoperability.” Interoperabi lity.” January, 2012. Federal Emergency Management Agency. “Agency Information Collection Activities: Proposed Collection; Comment Request.” Federal Emergency Management Agency. “Crosswalk of Target Capabilities to Core Capabilities.” Capabilities.” May 16, 2012. Federal Emergency Management Agency. “DM-OPEM Full Requirements.” February 19, 2009. Federal Emergency Management Agency. “National Preparedness Report.” Accessed May 3, 2012. https:// https://www.fema.gov/library/ www.fema.gov/library/viewRecord.do?id= viewRecord.do?id=5914 5914 Federal Emergency Management Agency Disaster Management Program. “Instructions for Using Usin g the NOAA.” February 28, 2010. http:/ ht tp:// /www.oasis-open.org /committees/download.php/31085/using_hazcollect_on_open20081106.pdf Frankel, Mark. New York City Office of Emergency Management. Interview June 2012. Graves, Neil. IPAWS Engineering Branch. Interview June 18, 2012. Gregory, John. KnowledgeCenter™. Demonstration on May 26, 2010. REFERENCES | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

37

Gustafson, John. Connecticut Department of Emergency Management and Homeland Security. Interview May 2012. Holguin-Veras, Jose and Jaller, Miguel. Rensselaer Polytechnic Institute. “Immediate Resource Resource Requirements After Hurricane Katrina: Policy Implications for Disaster Response.” 2010. Kant, Eric. NC4™. Interview June 19, 2012. Lannon, Tom. Putnam County Office of Emergency Management. Interview June 2012. LeFevre, Scott. FATPOT FATPOT Technologi Technologies, es, LLC. Interview Interv iew January 11, 2010. Maloney, Maloney, Chip. Unified Incident Command and Decision Support (UICDS). Interview November 24, 2009. Masterson, Tim. Buffalo Computer Graphics. Interview June 22, 2012. Miller, Guy. Monroe County Office of Emergency Management. Interview June 2012. National Preparedness Directorate (NPD) offers the Supporting Technology Evaluation Project (STEP) Evaluations. June 2012. 20 12. www.rkb.us (keyword STEP) NC4™. “ET “ ETeam eam Functionality.” Functi onality.” Accessed June 5, 2012. http:// http://www.NC4.us/ETeam.php. www.NC4.us/ETeam.php. New Jersey Department of Health and Senior Services. Serv ices. Hippocrates. Hippocrate s. https://hippocra https://hippocrates. tes. nj.gov/. NIEM Program Program Management Office. “NIEM Implementation Implement ation Guidelines.”Accessed Guidelines.”Accessed June 10, 2012. http:// http://www.niem.gov/implementati www.niem.gov/implementationguide.p onguide.php. hp. OASIS. “Common Alerting Alertin g Protocol (CAP).” (CAP).” Accessed June 7, 2012. http:// http://docs.oasisopen.org/emergency/cap/v1.2/CAP-v1.2-os.html OASIS. “Emergency Data Exchange Language – Distribution Element (EDXL-DE).” Accessed June 7, 2012. http://www http://www.oasis-ope .oasis-open.org n.org/ /committees/ committees /download.php/17227 download.p hp/17227/ / EDXL-DE_Spec_v1.0.html OASIS. “Emergency Data Exchange Language – Resource Messaging (EDXL-RM).” Accessed January 24, 2010. http:// http://docs.oasis-open.org docs.oasi s-open.org /emergency/edxl-rm emergency/edxl-rm/ /v1.0/ EDXL-RM-SPEC-V1.0.doc. Rafferty, Tom. Tom. New Jersey State Police. Interview I nterview May 31, 31 , 2012. Regional Interoperability Management Solution Planning Team. Meeting Minutes June 2009. Schneyer, Ed. Suffolk County Department of Fire, Rescue, and Emergency Services. Interview June 7, 2012. Supporting Supporti ng Technology Technology Evaluation Project. Accessed Access ed June 7, 2012. https:// https://www.ptaccenter.org/step/index. Thinkstream. http://www http://www.thinkstream.com .thinkstream.com.. Unified Incident Command and Decision Support (UICDS). (UICDS). “UICDS in Brief.” Brief.” March 4, 2010. http://www.uicds.us.

38

REFERENCES | CONFIDENTIAL. FOR OFFICIAL USE ONLY

Unified Incident Command and Decision Support (UICDS). “UICDS Overview for Technology Providers.” March 4, 2010. http:/ ht tp:// /www.uicds.us. Williams, Dave. Pennsylvania Emergency Management Agency. June 2012. Wind, Jason. Federal Emergency Management Agency. Interview June 20, 2012.

RMS Planning Team

Agency

Name

ARDEC

Ekta Patel

ARDEC

Aaron Lieb

Connecticut Capitol Region Emergency Planning Committee

Carmine Centrella

CT DEMHS

Robert Scata

CT DEMHS

Bill Tessier

CT DEMHS

John Gustafson

DHS Office of Emergency Communications

Chris Tuttle

DHS S&T

Mitch Erickson

Evolution Technologies, Inc.

Tim Grapes

FEMA Region II

John Alonso

FEMA Region II

Laura Swedlow

FEMA Region II

Jason Wind

MITRE Corporation

Don McGarry

Monmouth University

Jim Hammil

Monmouth University Rapid Response Institute

Bob Kelly

Monmouth University Rapid Response Institute

Barbara Reagor

Monroe County Monroe County Office of Emergency Services

Guy Miller

Morris County OEM

Raymond Hayling

New York City OCME

Hassan Adekoya

New York City OEM

Erin Bores

New York City OEM

Daniel Casey

New York City OEM

Mark Frankel

New York City OEM

Henry Jackson

New York City OEM

Jonathan Jenkins

New York City OEM

Dennis Quinn

New York City OEM

Michael Schultz

REFERENCES | CONFIDENTIAL. FOR OFFI CIAL USE ONLY

39

For more  information please contact:

New York York City OEM / Regio Regional nal Logistics Program

Kiran Dhanji

New York York City OEM / Regio Regional nal Logistics Program

Alex Markowski

New York State DHSES

Rick French

New York State DHSES

David DeMatteo

New York State DHSES

Nadine Macura

New York State DHSES

Kevin Ross

New York State DHSES

Jay Jobel

NJ Department of Health and Senior Services

Eileen Troutman

NJ OHSP

Scott Costello

NJ OHSP

Gene Haplea

NJ OHSP

Brad Mason

NJ OHSP

Jennifer Michalchuk

NJ OHSP

Jon Morgan

NJIT Business Force

Col. Henry Straub

NJIT Emergency Management Business Continuity Program

Mike Chumer

NJSP OEM

Tom Rafferty

Northampton County Emergency Management Services

Bob Mateff

Regional Logistics Program

Pearl Cheng

Regional Logistics Program

Detgen Greeff

Regional Logistics Program

Jim Penta

Regional Logistics Program

Alexander Marks

Regional Logistics Program

Sandra Woods

Warren County OEM

Bill Hunt

Warren County OEM

Frank Wheatley

Westchester County OEM

Dennis DelBorgo

Westchester County OEM

Noah Goldberg

• •

Jim Penta, Program Manager Detgen Greeff, Project Coordinator www.EmergencyLogistics.org/Contact-Us

40

REFERENCES | CONFIDENTIAL. FOR OFFICIAL USE ONLY

IC      P   C  T ROPH I  L 

  T A S   C A    L   A

A N  

N    I     N    G   

   N

   O      I

T     E     A    

   G     E     R

M    

N     e     w    

    a         i     n

   a

     v

Y     

Produced by the Regional Logistics Program www.EmergencyLogistics.org

      l    y     s

o   

r     

k    N    e  

   n    n

w  

J  e 

r   s e  e 

   t   u  c   t  i c  e c

y  Con n

   P  e

 APPENDIX D Sample Resource-Specific Data Collection Form

70

71

72

73

74

75