BCG Response to NYSOEM Draft Sandy AAR February 24, 2014 Executive Summary The Sandy After Action

Report draft includes 6 major inaccuracies and falsehoods about the DLAN system that need to be specifically addressed. 1. The report says that DLAN crashed during Sandy operations. DLAN never crashed during Sandy operations. While there were some other issues with NYSOEM IT infrastructure that were beyond the control of BCG and may have temporarily prevented users from accessing the system for brief time periods, DLAN never crashed during Sandy. 2. The report says that NYS is the only state to use DLAN and OEM is the only major emergency management agency at any level in NY that uses DLAN. DLAN is used in 6 states and 9 counties within in NY, as well as numerous other locations across the US and Canada. DLAN is in use by the State of Vermont, the State of MN, the US territory of Guam, the regions of Halton and Ontario Canada, and inumerous counties and cities in states throughout the country from New York to California. Additionally, within NYS DLAN is utilized by Chautauqua, Cattaraugus, Erie, Niagara, Ontario, Rockland, Westchester, Livingston, and Orange counties, as well as the Seneca Nation of Indians and the NYS National Guard in Albany. It is also important to point out that many, many more counties are trained in DLAN and have accounts on other county systems. 3. The report says that DLAN is incompatible with other systems. DLAN is fully NIMScompliant and can communicate with any other system that complies with federal interoperability standards. DLAN is the ONLY Crisis Incident Management System to have passed every NIMS-STEP evaluation test for interoperability and NIMS-compliance. DLAN supports the CAP & EDXL data interoperability standards promoted by FEMA/DHS in addition to email and web services data exchange. BCG cannot speak to other systems ability to share information interoperability, but we have always made the effort to meet all interoperability standards. 4. The report says that DLAN needs substantial on-site contractor support. DLAN does not need substantial on-site contractor support. NYSOEM requested, and BCG provided around the clock on-site support during Sandy, the vast majority of which was not DLAN related. As noted in the report, NYSOEM is understaffed, and many key personnel were shifted to the ROC in NYC leaving the EOC even more shorthanded. BCG personnel have extensive state-wide activation experience and were able to help fill some of the gaps, providing just 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 functional asset tracking and resources module and various iterations of these modules have been recommended to NYSOEM before, during, and after Sandy. Over the past several years, BCG has worked with NYSOEM staff to identify, design, and cost out the

ideal asset management system that could be used by their logistics staff. BCG provided NYSOEM with multiple cost-effective proposals, in advance of Sandy, that were not executed by the agency. 6. The report says that DLAN is insufficiently understood. BCG employees provided just-intime training for those unfamiliar with NYSOEM procedures and policies as well as with DLAN. DLAN is an extremely intuitive and easy-to-use system. The basic methodology for using DLAN can be explained in fifteen minutes or less. DLAN has been designed and configured to tightly integrate into NYSOEM operations and thus we do see value in including policy and procedure training along with DLAN software training - the two go hand-in-hand. As seen in this short synopsis, the Sandy After Action Report draft included several inaccuracies and falsehoods about BCG and our DLAN product. BCG wishes the authors of the report had provided BCG with a prior opportunity to address how DLAN performed during Sandy and particularly gotten feedback from our personnel who, as stated previously, were an active part of NYSOEMs response to Sandy. The lack of inclusion of any feedback from BCG in this report, the many mistruths about the DLAN product, and the final conclusion that DLAN should be replaced as NYS incident management solution bring the intentions of the author into question. The following pages address in detail the many false accusations laid against DLAN in this report and it is our hope that this information will give a more accurate assessment of NYSEOMs response to Sandy and both DLANs use and BCGs participation in this response.

Full Response As the vendor of the DLAN Crisis Incident Management System, BCG takes exception to many of the libelous and inaccurate assertions issued in the Sandy After Action Report draft. Having not been afforded the opportunity to participate in the AAR interviews to correct misconceptions or provide what we feel would have been important information, we will address the reports inaccuracies below. Should any party be interested in discussing the issues with us, we would be happy to do so. Report Assertion 1: DLAN, the emergency management support software used by OEM to collect and fulfill resource requests, is insufficiently understood by many staff, requires substantial on-site contractor support, and is incompatible with systems used by other jurisdictions and agencies (including, prominently, New York City, Suffolk and Nassau Counties). Response 1: DLAN does not require substantial on-site contractor support. While it is true that NYSOEM requested, and BCG provided, around the clock on-site support for the first several weeks of the Sandy response, the vast majority of the support provided was not DLAN-related. After years of working closely with NYSOEM, BCG staff has an in-depth understanding of their operating policies and procedures. As noted in the report, NYSOEM is understaffed and BCG personnel were able to fill some of the gaps and provide services in a number of non DLAN-related areas. These included conducting daily orientations and trainings of EMAC support teams, general IT support and problem solving, and aiding in building out the IT infrastructure in the NYC ROC. Appendix A provides a list of the activities performed by BCG staff during Sandy. Just-in-time training on DLAN was also provided, as would be expected with any software system utilized by mutual-aid personnel unfamiliar with both the software and organizational operations. BCG is proud of the services and support we provided NYS during Sandy and cannot stress strongly enough that our provided support went far-and-beyond what level of support was required for DLAN. Regarding the charge that DLAN is incompatible with systems used by other jurisdictions, again we take exception. DLAN is the ONLY Crisis Incident Management System to have passed every NIMS-STEP evaluation test for interoperability and NIMS-compliance (see Appendix B for a summary of FEMAs report). DLAN supports the CAP & EDXL data interoperability standards promoted by FEMA/DHS in addition to email and web services data exchange. BCG will not comment on the ability or willingness of other systems to share information interoperably, but will assert our ability and willingness to do so. We should also point out that for several years, BCG has been working with Regional Logistics Program on a pilot project to share information, specifically resource information, with other systems in use throughout the northeast. DLAN has always been at the forefront of this information exchange effort. See Appendix C for more information on the IEM interoperability effort. While it is true that NYC, Suffolk and Nassau Counties utilize systems other than DLAN, many

other counties do utilize DLAN systems. These include Chautauqua, Cattaraugus, Erie, Niagara County, Ontario, Rockland, Westchester, Livingston, and Orange, as well as the Seneca Nation of Indians. DLAN is also utilized by the NYS Department of Military and Naval Affairs as well as our cross-border Canadian partners in the Ontario and Halton regions of Canada. Additionally, since DLAN is a web-based solution, sold on a as a single-site license with no per-user charges, should NYSOEM opt to provide logins to a particular user or county, they will be easily able to access the system and the data within.

Report Assertion 2: The most frequent source of frustration expressed by those who have used DLAN on a regular basis is that personnel from other agencies as well as county emergency management agencies have not been adequately trained to use the system. Response 2: As with any software system, some amount of training is required. While DLAN does provide integrated help, training videos, and quick reference guides, much of the required training by NYSOEM users is policy and procedure based. DLAN has been designed and configured to tightly integrate into NYSOEM operations and thus we do see value in including policy and procedure training along with DLAN software training - the two go hand-in-hand. Ultimately, it is up to NYSOEM to determine if they want to provide training to county emergency management agencies and open up use of the system to them. BCG has, and continues to stand ready to provide any requested training, including just-in-time training during EOC activations (as we did for out-of-state EMAC mutual-aid personnel during Sandy). It should be noted that BCG conducted our own internal after action review of Sandy, and one of our recommendations going forward is that NYSOEM better utilize video and web-based training. For example, a just-in-time video training module could be produced so that when 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 on personnel required to conduct this necessary real-time training during a large event. This training can also be made available, via the Internet, to county emergency management agencies as well as NYS state agency users.

Report Assertion 3: Although the State has invested substantially over the past decade in making DLAN the electronic backbone for OEM incident management, it is widely viewed by emergency managers at the local level (as well as by other State agencies) as cumbersome, inefficient, and inflexible. In addition, other jurisdictions in New York have invested in other technologies that are unable to communication with DLAN. As a consequence, many officials across the State view DLAN as an impediment to effective incident management. Criticisms of DLAN were heard at every level of government and centered around problems of usability and compatibility. Specific objections include: Preparing a mission request form/ticket is time consuming and non-intuitive; Since DLAN is felt to be too hard to use, it is not used on a daily basis by most OEM staff nor by local-level responders, which means most personnel are not familiar with it operation; Tracking the status of specific entered requests is difficult, making management and planning for those resources and assignments challenging; DLAN does not readily allow users to generate custom reports - the DLAN contractor at the EOC must develop these for users; DLAN in not compatible with WebEOC and eTeam, the systems in use in most counties and major cities in the State, including New York City, which means data must be entered twice and that the databases downstate and in Albany cannot speak to each other. Additional complaints speak to gaps between what DLAN provides and what is needed to support logistics and procurement, particularly during a crisis. DLAN was never designed to be a resource management tool, but has the capability to do so with customization. However, unless the state and local jurisdictions are using the same system, or have the ability to interface with each others systems, resource management will continue to be an issue. Response 3: The fact that DLAN was designed with NIMS interoperability requirements in mind has been previously addressed and will not be revisited here. As for the claim that entering a ticket is time consuming, this is partially true. However this is by design to force users to enter all the data necessary for personnel to fulfill a resource request upfront instead of having partial data entered and then having to waste time later trying to find the needed information. This includes contact information as well as specific information about the resource being requested. While DLAN can be configured to allow for rapid and minimal data entry on a ticket, in the end, this approach will end up costing time instead of saving it. NYSOEM staff very deliberately designed and configured the DLAN ticket entry system so that all pertinent information necessary to fulfill a resource request is gathered. When considering how to configure the DLAN ticket entry system, a detailed survey was distributed to lead agency partners and county emergency managers based on real world use case scenarios. NYSOEM consulted with their lead agencies and counties around the state on these use cases to develop

and review the request forms to ensure the information being requested would allow for a more accurate and timely deployment of resources especially in life safety situations. This also allowed for more pre planning activities to be tied into the day to day use of the system. This may best be illustrated by way of example. Consider the case where a county requires a generator to operate a hospital. It is simply not enough to enter a ticket that states that Hospital X needs a generator. Additional information is critical to fulfilling this order. For example, what size generator is required, what type of fuel is available for the generator or does NYSOEM need to provide fuel for the generator as well, are there resources on site to off load the generator and wire it in or does NYSOEM need to provide personnel as well, and many other critical information points. To aid in collecting this information, resource-specific templates have been implemented in DLAN so that when someone designates a ticket as a Request for a generator, they are presented with the list of specific questions pertinent to a generator request which are required to be answered before a generator can be deployed (see Attachment D). Yes, this requires the person making the request to obtain this information, but there is really no other way to fulfill such a request without gathering the necessary information. While this does add to the length it takes to fill out a ticket in DLAN, it ultimately eliminates a lot of back and forth and can expedite resource deployment if the proper information is provided up front. Frankly, much of this information can and should be gathered during pre-planning so that precious time need not be wasted doing so during a response. IF NYSOEM wants BCG to remove these item-specific data collection forms from DLAN, we would be happy to do so. Yes, in the end it will speed up ticket entry, but you will also have a fraction of the information necessary to deploy resources and will increase the manpower and time required to ultimately collect this information in the end. This is a pay-me-now or pay-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 today is the result of years worth of use, ideas, suggestions, and improvements. BCG truly values and listens to our customers. The generic comment that DLAN is too hard to use typically is leveraged by people unfamiliar with and untrained in the use of the system. If specific areas of the system are considered too hard to use, we invite individuals to tell us exactly what areas and provide suggestions to make the system easier to use. We are always open to ideas and suggestions to improve the product. But, general statements without specific context and suggestions for improvement cannot be addressed. Regarding the statement that tracking of requests is difficult, we disagree on several fronts. First, every resource request in the system is given a unique ID number. It is very easy to recall a specific resource request by ID number so that the ticket can be opened and reviewed. Additionally, search tools allow users to rapidly locate a ticket based upon virtually any piece of information entered on the ticket should they not recall the ID number. Finally, each ticket is provided a color-coded status so that, at a glance, users can see the status of a ticket.

We should also point out that DLAN provides some additional tools for tracking and reporting on resource deployment. NYSOEM has thus far opted to not utilize these resource tracking tools, but they are available to them on their system. In terms of reporting, the assertion that DLAN does not readily allow users to generate custom reports , or what some other systems refer to as boards and/or inboxes is false. DLAN has an easy-to-use custom report generator that is available for use by any user. Just because users are unaware of or untrained in the use of such a tool does not mean that the tool doesnt exist. Additionally, the assertion that the DLAN contractor at the EOC must develop these for users is also blatantly false. During Sandy, BCG staff did take on the responsibility of generating hourly reports for review by senior management, but we did so because NYSOEM staffing was short. While staff could easily have generated these reports, they frankly were so overwhelmed with other duties that BCG staff stepped in to help. While we previously talked about interoperability, it is probably worth directly addressing again the assertion that DLAN in not compatible with WebEOC and eTeam, the systems in use in most counties and major cities in the State, including New York City This is false in two counts. As previously mentioned, DLAN has the technical ability to communicate and share information with these other systems should people desire to use the interoperability features. Also more counties in NYS utilize DLAN than WebEOC and E-Team combined. It might be worth pointing out how the State of Minnesota addressed similar concerns. In MN, the state, as well as many counties, utilize DLAN; but a few counties utilize Knowledge Center. MN approached BCG and asked if we could work with Knowledge Center to exchange information. Since Knowledge Center didnt support the FEMA/DHS IPAWS system for data exchange, BCG developed a custom web service to integrate with Knowledge Centers proprietary communications system. Today, both DLAN and Knowledge Center share information between systems in MN. The point being made here is that the issue of data sharing is not one of technology, but of will and policy. Now we need to address the issue of resource management, logistics, and procurement. While DLAN does have an asset/resource module, it is currently not utilized by NYSOEM. NYSOEM currently utilizes a standalone non-web-based product called TC-MAX for assets management. Over the past several years, BCG has worked with NYSOEM staff to identify, design, and cost out the ideal asset management system that could be used by their logistics staff. They envisioned a state-of-the-art web-based system that utilizes bar-coding, mobile hand-held devices, and GPS location tracking devices as the ultimate solution. The proposed BCG approach was to take DLANs existing resource module (which has 80% of the desired functionality), identify any gaps from the ideal system, and make necessary changes to DLAN to furnish the ultimate solution. BCG provided NYSOEM with multiple cost-effective proposals, in advance of Sandy, that never gained any traction within the agency. Specifically, the following proposals were provided to NYSOEM:

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

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

Report Assertion 4: DLAN crashed during Sandy operations (though other incident management software packages used in other jurisdictions also crashed under the workload) requiring contractor assistance to reboot. Some feel that being forced to have DLAN contractors in the EOC to support the software reflects the limitations of the product, is expensive, and constitutes a misuse/waste of limited floor space. Finally, observers felt that EOC staff was engaged in working with the DLAN system to the exclusion of communicating with other emergency operations center personnel. This compromised their ability to share information (this is, to be fair, another criticism that has been leveled against other software packages). Response 4: The assertion that DLAN crashed during Sandy is false. While there were some other issues with NYSOEM IT infrastructure that may have temporarily prevented users from accessing the system for brief time periods, DLAN never crashed during Sandy. It is important to understand that DLAN, like other web applications, relies upon other supporting technologies. For example, if the Internet to your home goes out and you cannot reach cnn.com, you should not assume that CNN is broken and blame CNN. Similar issues occurred during Sandy and I will outline the details below: During the day shift of 10/29/12, BCG detected a slowdown in Internet performance that was unrelated to the DLAN application. No other DLAN users noticed this slowdown, but BCG staff detected it because we had both on-site and off-site personnel performing continuing system monitoring. We immediately spoke with support personnel from NYSOEM IT who stated that they were aware of a DHSES network related bandwidth issue on their end and were looking into it. On 10/30/12 during the day shift, we were advised by NYSOEM IT that the wireless network was moved to another Internet pipe and everything seemed faster for external users. However, later that day at around 4:50 PM DLAN could not be accessed externally. DLAN continued to function internally at the EOC and for any users connected via a VPN connection. External user outside the DHSES network could not reach DLAN, DHSES email, DHSES Sharepoint servers, and other DHSES systems. This clearly was a bandwidth-related issue related to DHSES network and not a DLAN issue. BCG again spoke with NYSOEM IT who informed us that the whole NYSOEM Internet was failing and that they were looking into the issue. Other NYSOEM web sites could also not be accessed because of this Internet issue. Again, we must point out that DLAN did not crash, but may have been inaccessible to certain users because of the Internet bandwidth issue. Initially, it was believed that there was a failure in some external equipment on the AT&T network that served NYSOEM. However, the ultimate issue was detected by NYSOEM IT and was related to a saturation of the NYSOEM network by Google. Apparently, upon executive orders, a KML data feed tied to other DHSES systems unrelated to DLAN was provided to Google so that they could provide mapping data to their Google Maps product. Unfortunately, this had the untoward effect of saturating the NYSOEM network with data requests thereby blocking or preventing other traffic from passing. NYSOEM IT

10

immediately disabled this feed to Google and normal network operations resumed immediately. Another issue that occurred during Sandy that affected access to DLAN happened on 10/31/2012 during the day shift. Due to the large number of additional personnel operating out of the Albany facility, the network almost ran out of IP addresses. In order to resolve this, NYSOEM IT released some of the IP addresses they had in reserve but in doing so this caused some issues with the wireless network. Some users in the Albany EOC lost wireless connectivity and thus access to DLAN. While most users were not affected, to the ones who were, it appeared as if DLAN crashed, but it had not. Simply renewing the IP addresses for the affected individuals restored their network connectivity and access to DLAN. On 11/01/2012, the entire NYSOEM network had a brief failure (cause not known to us) which again affected peoples ability to access DLAN. But again, this was not a DLAN failure. At 10:15 AM on 11/01/2012, NYSOEM IT needed to failover one of their SQL databases. During the process of failing over this database, the failover process knocked out the SQL cluster upon which the DLAN database resides. Again for a brief time, users were unable to access DLAN, but this was not a failure of DLAN. The final event that impacted DLAN accessibility during Sandy occurred on 11/8/12 during the day shift. NYSOEM IT conducted a planned outage of their Storage Area Network (SAN) in order to replace a failed controller card. The maintenance interval ran from 12:15 to 1:30 PM. Because the DLAN database, like most other NYSOEM data stores, resides on the Piller SAN, DLAN was briefly inaccessible during this outage. Again, DLAN inaccessibility was not the result of a failure of DLAN.

11

Report Assertion 5: It is not an indictment of DLAN to note that only one other state uses the software, nor that OEM is the only major emergency management agency at any level in New York that employs it. Nor is it necessarily a criticism to observe that many urgent or high level requests were pushed through not using DLAN, and that the forms for many such tickets were completed after the fact. It is important, however, to recognize that the perception another example of the agencys dysfunction. The system has few supporters and many detractors, does not play well with others, and does not seem to do anything better than other, more widely accepted, competing systems. Response 5: The authors of the AAR inaccurately state that DLAN is used by only one other state and that OEM is the only major emergency management agency at any level in New York to employ DLAN. This is incorrect, and one can only assume written to dimunitize DLAN as a product. DLAN is in use by the State of Vermont, the State of MN, in the US territory of Guam, in the regions of Halton and Ontario Canada, and in numerous counties and cities in states throughout the country from New York to California. Additionally, within NYS DLAN is utilized by numerous counties (as outlined previously in this document) including but not limited to the large counties of Erie and Westchester. Also, when FEMA evaluated systems for use within their organization, DLAN rated as excellent overall with a rating of outstanding for past performance based upon customer interviews (see Attachment E). Regarding the statement that DLAN does not seem to do anything better than other, more widely accepted, competing systems, we cannot disagree more strongly. We are intimately familiar with competing systems, and feel strongly that DLAN is unique in the way information is managed in a workflow-based manner. In fact, there is an exhaustive list of features too numerous to fully mention here that are unique to DLAN and are not a part of any other incident management system available on the market including (just to mention a few) full IPAWS-OPEN integration, integration with NY-Alert, support for FEMA Project Worksheet finance tracking, and unified communications tools for monitoring third party information feeds. We are confident that DLAN does things much better than competing systems, and constantly hear from users of competing systems that they wish they could change to DLAN because their current system doesnt do anything for them but they cant change because they already invested heavily in another system. We encourage you, the reader, to carefully evaluate and compare DLAN to competing systems. Talk to users of other systems and see how their system performed in a large event. After conducting an exhaustive, fair comparison, we are confident that you will appreciate the capabilities, features and flexibility that DLAN offers. DLAN does have many supporters, within NYSOEM, within NYS counties, and throughout organizations nationally. Unfortunately, it appears as if the authors of this report either ignored DLAN supporters or specifically sought out DLAN detractors. One can only question the authors motivations.

12

Report Assertion 6: A modern asset tracking system tied to DLAN (or some other incident management support software package) and to the States procurement system, would streamline the acquisition and delivery of requested resource to parties that need them, help assure positive control during the operation, and facilitate recovery and return of rented, purchased and borrowed items. Response 6: We agree with this assessment. In fact, as stated previously, we have advocated for and proposed such a system to NYSOEM on previous occasions. In fact, during the response to Sandy, BCG provided a proposal to NYSOEM to procure up to 10,000 GPS AVL slap-and-track asset tags. Date 11/05/2012 Proposal Number Q2400 [DLAN Ticket #102860]

BCG went as far as to bringing our asset tracking logistics expert in from Texas into the ROC in New York City to help facilitate this effort. Our proposal, had it been accepted and acted upon, would have allowed us to tag up to 10,000 assets with a combination of satellite and cellular-network tracked AVL devices. Each asset would have been trackable on a map and complete location reporting would have been possible. BCG could have initiated the 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 asset tracking system should be tied to DLAN.

Report Assertion 7: The technology backbone of the State EOC is solid, but undercut by an incident management software system that is not accepted by the local communities that need to use it and a physical plant that is not conducive to efficient operations. Response 7: Again, we take exception to the statement that DLAN is not accepted by the local communities. In fact, DLAN is used successfully and enthusiastically used by numerous counties throughout NYS. Many of the comments we have heard from counties is that while they want to utilize DLAN, they have been prohibited from doing so by NYSOEM. Additionally, the DLAN customer base in NYS continues to grow with several counties currently interested in adding DLAN to their incident management tool set.

13

Report Assertion 8: DLAN should be replaced. A competitive process should select a replacement which is more flexible, better integrated with other systems in the State, and fully capable of providing the functionality and flexibility needed in an evolving emergency. Response 8: While we welcome an open, honest, head-to-head, feature-to-feature comparison between DLAN and other systems, we disagree with the assertion that DLAN should be replaced. We strongly believe that the complete feature set, custom integrations, flexibility, and rich capabilities of DLAN are not understood by the authors of this report, by the numerous untrained individuals who responded to Sandy, or by NYSOEM executive management. NYSOEM Warning Point, Operations, and Planning staff are well training in the advanced capabilities that DLAN provides and their staff depends on them to meet the daily requirements of their job. The authors even go as far as to admit this by stating that it should be noted that OEM personnel familiar with and trained in the use of DLAN feel it is an effective tool for supporting EOC operations. As we have shown in our response, the draft AAR report is riddled with inaccuracies, misinformation, and mistruths. We contend that not enough weight was given to DLAN supporters during the assembly of this draft report, and that ignorance regarding DLANs configuration and capabilities has led to many of the inaccuracies of this report. As stated at the beginning of this document, we must also reiterate that BCG was never interviewed during the report creation process. Had BCG been given the opportunity to address these inaccuracies, perhaps this report would have more accurately reflected reality.

14

APPENDIX A Services that BCG provided to NYSOEM during Hurricane Sandy Activation

At the request of NYSOEM, BCG was called upon to provide on-site staffing to NYSOEM for the response to Hurricane Sandy both pre-landfall and post-landfall. NYS initially requested 24/7 support for the Albany EOC, but ultimately requested additional support for the establishment of a New York City Regional Operations Center. Per the request of NYSOEM, BCG provided cost proposals for the requested staffing levels, and upon execution of a work order, BCG deployed the requested personnel to the EOC. At the end of each period of performance, NYS assessed their need to have BCG continue their support of the operation, and BCG again provided a quotation to NYS based upon the level of support requested. NYS then would issue another work order and BCG would maintain or deploy personnel as required. This process repeated until such time that NYSOEM determined that support was no longer required. During the activation, BCG personnel provided numerous services both related to and not related directly to BCG product offerings. BCG personnel were willing to provide any type of support requested by NYSOEM. Below is a sampling of the activities/services provided by BCG: Provided 24/7 support to the Albany EOC Served as liaison to incoming EMAC teams and provided: Just-in-time training on DisasterLAN Training on NYSOEM operating procedures, policy and workflow Orientation to EOC facilities and introduction to personnel Creation of user accounts and configuration of required security settings BCG typically BCG typically ran one large group training and 20-25 small training sessions each shift. Provided DLAN and other job duty training to NYS agency personnel as the rotated inand-out of the EOC Built training videos and quick reference sheets to help supplement NYSOEM workflow and DLAN training Just-in-time web and over the phone training for NYSOEM regional staff deployed to affected counties Created DLAN user accounts, roles, and security permissions as needed to support new accounts, changing user requirements, and changes in EOC operations throughout the incident Handled password resets Created custom reports (hourly, shift, and daily) to support the dynamic needs of the NYSOEM EOC, NYSOEM ROC, NYSOEM Regions, Nassau County, Suffolk County, State Agencies, and other affected counties. Some sample reports included: Neglected ticket reports Custom reports based upon type of resource request Custom reports based upon agency 15

Summary activity reports Graphs and charts Outstanding resource requests in various stages of processing by NYSOEM Provided custom data exportation and importation Supported NYSOEM IT with server equipment troubleshooting and advanced NYSOEM process support to overcome NYSOEM technology issues as needed. Activities included: Supporting NYSOEM Operations when the Oracle Pillar SAN failed on 11/8/2012 Supporting NYSOEM Operations with paper copies of tickets and backed up reports when the Oracle Pillar SAN failed on 11/23/2012 Troubleshooting of the NYSOEM wireless network which became overloaded by users several times during the incident Troubleshooting of the NYSOEM external network which became overloaded by external user bandwidth requirements several times during the incident Troubleshooting EOC user issues on NYSOEM networks, computers, and equipment several times during the incident Troubleshooting of DMNAs DLAN server hardware hosted in NYSOEMs datacenter several times during the incident Assisting with backups of DMNAs and NYSOEMs DLAN servers several times during the incident Supported NY-Alert with server equipment troubleshooting and advanced NY-Alert process support to overcome NY-Alert technology issues as needed. Activities included: Spent a large amount of time monitoring and troubleshooting issues that occurred under heavy system load, which eventually led to the determination that NY-Alert did not have enough Email Servers. Assisted Kevin Ross in configuring 4 new email servers. Created a Software Load Balancer in NY-Alert that could more evenly distribute emails between all of our SMTP Servers during heavy load Created new custom features for NY-Alert to support Hurricane Sandy activities including: Added the ability to dynamically add new Email Servers without interrupting service Added a special managed re-try handler for a particular types of issues NY-Alert encountered with NWSs Weather Alert Feeds Added the ability for notifiers to specify that a particular Group Notification use link-based security only: i.e. anyone with the link to the notification can view it. Added a cache control mechanism to the public alert map to avoid issues where, under heavy load, old data would remain cached too long instead of updating when it should Provided custom NY-Alert importation and configuration to support a transfer for NYC alerting system to NY-Alert Routine hourly backups of tickets for NYSOEM Operations Routine hourly backups of status board slides for NYSOEM Planning Configuration changes to DLAN modules to support NYSOEM Branches

16

Research and custom integration with Gentrifi AVL and WDT weather data feeds to support NYSOEM EOC operations Custom data cleanup to fully fill out tickets for people who entered incomplete data Provided requested support to New York City Regional Operations Center. Activities included: Staffed the New York City Regional Operations Center to provide training on NYSOEM workflow, NYSOEM policies and procedures, and resource requesting on DLAN for State Police, Public Service Commission, and military personnel coming to support the operation Coordinated with NYS GIS (Frank Winters) to support GIS data sharing needs throughout the incident Created graphical maps of proposed floor plan layouts Worked with NYSOEM staff to physically wire the Regional Operations Center in NYC. Activities included: Running wires Installing Wireless Access Points Assisted in loading and unloading equipment and cargo for the ROC to help support NYSOEM Operations and DHSES IT Installing printers Distributing and configuring laptop computers Assisted in loading and unloading equipment and cargo for the ROC to help support NYSOEM Operations and DHSES IT Researched advanced system-to-system replication options to help support DHSES IT Troubleshooting of network, Internet, and bandwidth issues to help support DHSES IT

17

18

APPENDIX B NIMS-Step Evaluation Summary Report

19

20

21

22

23

APPENDIX C Regional Logistics Program

24

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 Contents
Preface Using this Document Overview Overview of Existing Systems Information Sharing Mechanisms     2 3 4 6

12 Connecticut  New Jersey 14 New York 14 Pennsylvania15 State-to-State (EMAC) 16 Federal16 Existing Standards-Based Information Sharing Capabilities    17 20 22 25

Information Sharing Capabilities Adopting EDXL-RM Implementing EDXLRM in the Region Establishing Regional Operational Coordination Appendices

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

28 29 32

References

33 Glossary Acronyms35 Bibliography37 Planning Team List 39 Contact Information 40

Preface
Established in 2008, the Regional Catastrophic Preparedness Grant Program (RCPGP) is a groundbreaking Department of Homeland Security initiative to encourage collaborative emergency planning in Americas largest regions. The New York-New Jersey-Connecticut-Pennsylvania (NY-NJ-CT-PA) Region includes four states, 30 counties, hundreds of cities, towns and villages, and spans three FEMA regions. With a population of 22,000,000 people, this region is home to nearly 1 in every 14 Americans. The Regional Resource Management Solution (RRMS) project was executed by the NY-NJ-CT-PA RCPGP Regional Logistics Program, under the guidance, supervision and oversight of the Regional Catastrophic Planning Team (RCPT), and with contributions from the multi-jurisdictional Regional Information Management Solution (RIMS) Planning Team. The document is focused on jurisdictions in the NY-NJ-CT-PA RCPGP Project Site (hereafter, the Region); however, any agency or jurisdiction is welcome to use this information in any capacity in which it may be found useful.

Using this Document

This Assessment Paper summarizes the objectives and presents the conclusions and findings of the Regional Resource Management Solution (RRMS) initiative. Find project goals, objectives, and status. Find an overview of existing technology systems in the Region. Review current mechanisms for information sharing in the Region. Learn about EDXL-RM and its potential as a data interoperability solution.
4 6 12 20

The RRMS Regional Data Interoperability and Resource Management Assessment Paper is part of a comprehensive suite of disaster logistics documents created by the NY-NJ-CT-PA Regional Logistics Program. The entire suite of documents, including a strategic CONOPS, operational plans, field operations guides, assessment papers and toolkits, can be found at http://www.EmergencyLogistics.org. Together, these documents create the framework for a Universal Logistics Standard, providing guidance and tools that allow emergency managers and logisticians to prepare and implement a robust and effective disaster logistics capability.
USiNG tHiS dOcUmENt | COnfidential. FOr Official Use Only

Overview
This document is designed to help logisticians develop plans to improve data-sharing capabilities in their incident management systems.
The National Preparedness Goal, published by the United States Department of Homeland Security (DHS) in September 20111, stresses the importance of operational coordination and interoperable data communications between federal, state and local first responders. It emphasizes maintaining a core capability for operational communications to ensure the capacity for timely communications in support of... operations by any and all means available, among and between affected communities in the impact area and all response forces. This assessment paper explores technology solutions that support the National Preparedness Goal and allow jurisdictions to maintain operational coordination and operational communications. Goal Define a regional path forward to seamlessly connect local, state and federal technology systems and automate how information is received, shared and tracked as resources are requested and deployed during disaster response. 1 Provide an overview of the existing technology systems used in the Region. 2 Assess how information is currently shared between existing technology systems 3 Identify data standards that enable jurisdictions to share resource request and tracking information. 4 Evaluate potential middleware and other solutions that integrate with the Regions current systems, seamlessly connecting multiple levels of government and enhancing interoperable communications while allowing jurisdictions to keep their existing technology systems. 5 Evaluate potential solutions to improve the visibility of critical assets, resources, supplies and equipment that are deployed after a disaster.

Objectives

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

OVErViEW | COnfidential. FOr Official 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 and beyond. The Planning Team played a critical role in developing the strategy for improving regional interoperability to support resource management. Contacted 30 counties and 4 states to gather information on the technology systems used by each jurisdiction in the Region. Generated consensus among Planning Team members to recommend an open, published data standard for interoperable data-sharing on any current or future technology projects. Compiled information on both challenges and best practices for regional interoperability and resource management. Identified baseline capabilities that all technology systems must have in order to support interoperable data sharing. Identified two federally-developed, no-cost options to link the Regions technology systems. The RIMS Planning Team remains an active working group that seeks to further the objectives of the RRMS initiative. A discussion of possible solutions and next steps is provided at the end of this paper.

OVErViEW | COnfidential. FOr Official Use Only

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 resource management and information sharing.
In order to effectively manage resources a IMS user must be able to: Order and acquire resources Mobilize resources Track, inventory and report resources Facilitate resource reimbursement

Existing Technology within the Region

DisasterLAN, developed by Buffalo Computer Graphics E Team, developed by 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
NY CT NJ

Version 3.x Knowledge Center Version 3.9.2 Web EOC Version 7.4.0.4

PA

State Agency Systems

Evaluating IMSs for implementation

OVErViEW Of ExiStiNG SYStEmS | COnfidential. FOr Official Use Only

DisasterLAN

DisasterLAN2, the IMS used by the New York State Division of Homeland Security and Emergency Management (NYS DHSES) and several county emergency management agencies within New York State, was created by Buffalo Computer Graphics (BCG) in 2001. At the request of NYS DHSES it has been significantly upgraded and modified to closely resemble the agencys paper-based processes. DisasterLAN is a web-based system that is built on an SQL server. The software is customizable, and sold as a per-site license. Because it is web-based, anyone with proper security privileges and a web browser can access it. It can be deployed on a dedicated or shared server or can be hosted virtually at DisasterLANs data center. DisasterLAN recommends all site installations be updated regularly to ensure that the most current version of its software is always deployed for its users; however, all fielded systems remain interoperable regardless of version. The most recent version, DisasterLAN version 8.0.5, added a web-based graphic interface that has been enhanced for mobile-web browsers. Version 8.0.5 also has been upgraded to conform with IPAWS 3.0 interoperability, and is capable of casting messages via the Commercial Mobile Alert System (CMAS). DisasterLAN supports resource management through three main modules: Call Center:3 A flexible data entry system that is optimized for EOC information management requirements and can be used to manage NIMS typed resources and track the full lifecycle of a resource request, including its fulfillment and deployment. Preplanning:4 A tool that can be used to manage information on suppliers and stockpiles. Resources can be matched to call center tickets requesting or donating resources. Interoperable Messaging:5 A tool that can be used to send and receive standardscompliant messages, while allowing access to information (such as resource tickets, etc.) in a template-driven interface. DisasterLAN is the only IMS in use within the Region that has been evaluated by the National Incident Management System Supporting Technology Evaluation Program (NIMS-STEP), and is therefore the only system out of the four to be certified as NIMS compliant in Emergency Data Exchange Language (EDXL) and Common Alert Protocol (CAP) messaging standards.6 Find more information on the NIMS-STEP in Appendix A.

2 Reviewed by Tim Masterson, DisasterLAN software Manager, BCG. June 22, 2012 3 Buffalo Computer Graphics. DisasterLAN Call Center Ticket Manager. Buffalo Computer Graphics. Accessed on 16 May 2012 from http:/ /www.buffalocomputergraphics.com/documents/DLAN%20 Call%20Center%20Slick.pdf 4 Buffalo Computer Graphics. DisasterLAN Preplanning Module. Buffalo Computer Graphics. Accessed on 16 May 2012 from http:/ /www.buffalocomputergraphics.com/documents/DLAN%20 Preplanning%20Slick.pdf 5 Buffalo Computer Graphics. DisasterLAN Interoperable Messaging Module. Accessed on 16 May 2012 from http:/ /www.buffalocomputergraphics.com/documents/interoperable-messaging.pdf 6 Results from each evaluation may be accessed at www.rkb.us (keyword STEP). Accessed June 2012.
OVErViEW Of ExiStiNG SYStEmS | COnfidential. FOr Official Use Only

Jurisdictions Using DisasterLAN New York State Division of Homeland Security and Emergency Management (NYS DHSES) Westchester County Office of Emergency Management Orange County Division of Emergency Management Rockland County Department of Emergency Management

Version Version 8.0.57

Version 7.5.08 Version 7.5.0 Version 8.0.59

E Team

NC4s E Team, a IMS used by New Jersey and multiple agencies throughout New York State, provides users with interactive views on incident summaries, response operations, resource requests and deployments.10 E Team can be accessed using most web browsers and the system is server agnostic, meaning that it can be run on Oracle, SQL, or other servers. System access and authentication is controlled by a role-based data-sharing and security model that can be integrated with any existing Active Directory installation. Managing E Teams back-end database requires no knowledge of database programming languages; data can be filtered and displayed via E Teams Web Services architecture. Although E Team is considered an off-the-shelf incident management solution, its Web Services architecture makes it fully customizable and easy to integrate with existing plans and processes.11 E Team supports resource management through two separate reporting tools: Critical Assets: A tool that allows an agency to maintain an inventory of assets and resources, and tracks their availability, location and characteristics. Resource Requests: A tool that tracks separate resource requests using different status notations, such as Delivered, En Route, or Sourcing.

7 Interview with Tim Masterson, DisasterLAN Software Manager, BCG. 22 June, 2012. 8 Westchester and Orange counties plan to upgrade to version 8.0.5 by Fall 2012 as per Tim Masterson, DisasterLAN Software Manager, BCG. June 2012. Confirmed by Patrick Cerra, Buffalo computer Graphics, July 2012. 9 Interview with Tim Masterson, DisasterLAN Software Manager, BCG. 22 June 2012. 10 E Team: Functionality. NC4. Accessed from http:/ /www.NC4.us/ETeam.php on 5 June 2012. 11 Interview with Eric Kant, Interoperability Architect, NC4. 19 June 2012.

OVErViEW Of ExiStiNG SYStEmS | COnfidential. FOr Official Use Only

Jurisdictions Using E Team New Jersey State Police, Office of Emergency Management All county-level emergency management agencies in New Jersey New York City Office of Emergency Management (county-level emergency management duties in Bronx, Kings, New York, Queens and Richmond counties) Dutchess County Department of Emergency Response Suffolk County Department of Fire, Rescue and Emergency Services Nassau County Office of Emergency Management

Version Version 9.512 Version 9.513 Version 9.514

Version 6.x15 Version 3.x16

Version 9.0217

12 Interview with Tom Rafferty, Emergency Management Section of the New Jersey State Police. 31 May 2012. The New Jersey State Police OEM is currently in the process of upgrading their E Team IMS to Version 9; the upgrade should be complete by summer 2012. 13 Interview with Tom Rafferty, Emergency Management Section of the New Jersey State Police. 31 May 2012. 14 Interview with Mark Frankel, New York City Office of Emergency. June 2012. NYC OEM is currently in the process of upgrading their E Team IMS to Version 9.5. 15 Interview with Kenneth Davisdon, Dutchess County Department of Emergency Response. 7 June 2012. 16 Interview with Ed Schneyer, Director of Emergency Preparedness for Suffolk County Department of Fire, Rescue and Emergency Services. 7 June 2012. 17 Interview with John Bruckbauer, Nassau County OEM, 7 June 2012.
OVErViEW Of ExiStiNG SYStEmS | COnfidential. FOr Official Use Only

KnowledgeCenter

KnowledgeCenter is a web-based information management and communications tool developed by KnowledgeCenter Inc. and used by Pike County, PA. KnowledgeCenter is built on a SQL database and is sold as an enterprise licensed solution. KnowledgeCenters database can be hosted by a third party or installed in a local data center. Its team ensures that all clients are running the most up to date version of the software, which is extremely scalable and capable of supporting a high volume of users. KnowledgeCenter supports resource management in three ways: The Resources Module: A tool that allows users to manage resources as they are requested and deployed for an incident. While the interface is simple and user-friendly, the underlying structure of the Resources module can support the more-advanced supply chain management (SCM) best-practices that would greatly assist responders in managing resources for a large-scale, multi-jurisdictional catastrophic incident.18 The Incoming Requests Dashboard: A tool that provides users with an overview of met needs and unmet needs and gives them the option to accept or decline resources based on what they already have. The Incident Status Board: A tool that shows users the active incidents in a defined area. Jurisdictions Using KnowledgeCenter Pennsylvania Emergency Management Agency (PEMA) Pike County (as part of the Northeast Pennsylvanian Regional Counter-Terrorism Task Force, which also includes Carbon, Lackawanna, Lehigh, Monroe, Northampton, Susquehanna, and Wayne Counties) Version Version 3.9.219 Version 3.9.220

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

10

OVErViEW Of ExiStiNG SYStEmS | COnfidential. FOr Official Use Only

WebEOC

WebEOC is a web-based collaboration-oriented IMS developed by ESi used by the Connecticut Department of Emergency Management and Homeland Security (CT DEMHS) and will be rolled out in all ten FEMA Regions beginning in August 2012.21 The software runs on a Microsoft SQL server with a backend database consisting of multiple status boards which allow an agency to generate, post, transmit, and share information in real-time among its users. While resource requests are posted to an Incident Status Board for management of an individual incident, a Resources Status Board enables users to manage an inventory of an agencys resources.22 Although the standard installation of WebEOC comes with a number of status boards, clients must purchase additional optional features in order to achieve interoperability with older versions of WebEOC or other incident management solutions. These optional add-ons include GIS integration status boards and the WebEOC NIMS-compliant Resource Manager plug-in, which provides users with the capability to catalog and deploy resources as prescribed through NIMS23 using three main components: Resource Inventory Requests Deployments24 Jurisdictions Using WebEOC Connecticut Department of Emergency Management and Homeland Security Connecticut Department of Emergency Management and Homeland Security Administrative Regions (including Regions 1, 2, and 5 within the Region) Version Version 7.4.0.425

Version 7.4.0.426

21 Interview with Jose DosSantos, FEMA Region 2. September 2012. 22 WebEOC Professional Version 7. ESi. Accessed from http:/ /www.esi911.com on 2 February 2010 23 WebEOC Resource Manager 2.0. ESi. Accessed from http:/ /www.esi911.com on 2 February 2010. 24 http:/ /www.slideshare.net/RIEMA/WebEOC-resource-manager accessed June 2012. 25 Interview with John G. Gustafson, Emergency Telecommunications Manager for Connecticut Department of Emergency Management and Homeland Security. May 2012. 26 Interview with John G. Gustafson, Emergency Telecommunications Manager for Connecticut Department of Emergency Management and Homeland Security. May 2012.
OVErViEW Of ExiStiNG SYStEmS | COnfidential. FOr Official Use Only

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 pathways that include in-person conversations, phone calls, radio, paper documents, e-mail and facsimiles. These methods of ordering and tracking resource requests limit visibility into the status of the request and may duplicate processes and increase opportunities for error. The figure below depicts the current process of coordinating resource requests among local, state and federal agencies using these conventional pathways.

REGIONAL RESOURCE MANAGEMENT SOLUTION: RESOURCE REQUESTING

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

Current Request Process

STATE

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

FEDERAL

Requests unable to be filled with state resources or EMAC are manually submitted to FEMA as Action Request Forms (ARFs). FEMA coordinates with federal agencies and national resources to fulfill the ARF.

@ ? !
INCIDENT
215 ARF

@ ? !

STATE RESPONSE

LOCAL RESPONSE

? !

EMAC

FEDERAL RESPONSE

LOCAL

PROPOSED PROCESS BEGINS

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

EOC SYSTEM

INCIDENT

STATE FEDERAL Local and state partners use IMSs to manage resource requests, but often the systems Requests that cannot be fulfilled locally are Requests unable to be fulfilled through state electronically transmitted to the state EOC's system, resources or EMAC are these submitted to FEMA through cannot talk to one another or share data. It is also unclear whether existing which shares information with state asset databases an Action Request Form (ARF). Ideally, FEMA systems would be to a large surge in resource requests a ARFs and able agencies tomanage fill it. The request may also be develops new capabilitiesfollowing to accept and track transmitted to an EMAC system. electronically. catastrophic incident. In the three months following Hurricane Katrinas landfall, FEMA received 864 unique Action Request Forms27 (ARF), a 900% increase on the of similar magnitude were per-disaster agency average of 95 ARFs.28 If a catastrophe EOC SYSTEM EOC SYSTEM AR F to affect the NY-NJ-CT-PA Region, which is home to 22 million people, a 900% surge in resource management activities could require an even greater response. To manage such a response, agencies in this Region should consider opportunities for incorporating information sharing capabilities within their IMSs.
EMAC
MUTUAL AID

27 Miguel Jaller and Jose Holguin-Veras. Immediate Resource Requirements After Hurricane Katrina: Policy Implications for Disaster Response. (Rensselaer Polytechnic Institute, 2010), 7. 28 Federal Emergency Management Agency. Agency Information Collection Activities: Proposed FEDERAL LOCAL STATE OTHER LOCAL RESPONSE RESPONSE RESPONSE Collection; Comment Request. Federal Register. 69, no. 39 (2004): 9350. SYSTEMS

12

iNfOrmatiON SHariNG mEcHaNiSmS | COnfidential. FOr Official Use Only

CURRENT PROCESS BEGINS

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 REGIONAL RESOURCE MANAGEMENT SOLUTION: RESOURCE REQUESTING capabilities allow private partners to automate many of the tasks which emergency managers currently perform manually. Standards-based automation would allow LOCAL STATE FEDERAL The incident command requests a resource via If the request cannot be filled locally, it is submitted Requests unable to be filled with state resources or emergency to: phone or ICS Form 215. The EOC manually managers to the state EOC via phone, e-mail, and direct EMAC are manually submitted to FEMA as Action inputs requests into its tracking system and coordination, which works individually with state Request Forms (ARFs). FEMA coordinates with federal Streamline the resource request process by automating the transmission of data on individually works with local partners to fill it. resources, partners or EMAC to fill it. agencies and national resources to fulfill the ARF. requests, fulfillment and deployment. Reduce errors in resource requests by eliminating data-entry duplication. Boost visibility real-time @ into resource request and deployment processes through @ tracking of resources and seamless, automated information sharing. ARF Automating the transmission of resource requests would greatly improve the STATE efficiency with which the Regions existing plans and procedures are executed. The RESPONSE Region should look to interoperability as a way to expand the capabilities of its existing plans and procedures to efficiently manage resources in a catastrophe.
LOCAL RESPONSE

? !

? !

INCIDENT

215

? @ ! Proposed Request Process

STATE

EMAC

FEDERAL RESPONSE

LOCAL

PROPOSED PROCESS BEGINS

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

Requests that cannot be fulfilled locally are electronically transmitted to the state EOC's system, which shares information with state asset databases and agencies to fill it. The request may also be transmitted to an EMAC system.

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.

FEDERAL

EOC SYSTEM

EOC SYSTEM

AR F

EOC SYSTEM

INCIDENT
MUTUAL AID

EMAC

LOCAL RESPONSE OTHER LOCAL

SYSTEMS

STATE RESPONSE

FEDERAL RESPONSE

Connecticut

In Connecticut, five CT DEMHS administrative regions coordinate interactions between municipal and state government. Both CT DEMHS and its administrative regions utilize WebEOC, and CT DEMHS has granted all municipalities access to its WebEOC web-portal. Accordingly, information across all levels of government in Connecticut can be managed through WebEOCs various status boards, which are shared among all users. Connecticut is currently participating in a FEMA Region I pilot project using Virtual USA. This product not only receives inputs from WebEOC but allows integration of a variety of other GIS products which use different platforms. This product is likely to become the primary method for information sharing in New England.29
29 Conversation with John G. Gustafson, Emergency Telecommunications Manager for Connecticut Department of Emergency Management and Homeland Security, May 2012.
iNfOrmatiON SHariNG mEcHaNiSmS | COnfidential. FOr Official Use Only

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 pathways such as e-mail, phone and fax. NJ OEM is spearheading an effort to upgrade the states version of E Team 2.4 to version 9.5, the latest release of the software from NC4; the states upgrade to version 9.5 is scheduled for completion in the summer of 2012. The state plans to transfer all data and consolidate all servers onto one cloud-based server maintained at a facility in central New Jersey.30 Once the transfer is complete, all users in New Jersey will be able to use the system through a standard internet connection. This will make information sharing among users of New Jerseys E Team easier and more reliable.

New York

Due to New York States strong home-rule tradition, county-level OEMs have complete authority over the choice and use of a IMS, resulting in a wide variety of IMSs in use across the state. The New York State Division of Homeland Security and Emergency Management (NYS DHSES), along with several county OEMs such as Westchester, Rockland and Orange County, use Buffalo Computer Graphics (BCG) DisasterLAN. Entities that use DisasterLAN version 7.3.1 or above can communicate with one another directly from system to system using DisasterLANto-DisasterLAN messaging, or via interoperable standards such as EDXL-DE, and CAP. County OEMs that do not own their own DisasterLAN can either use the States DisasterLAN web portal, email, or IPAWS-OPEN to convey information to the state. All DisasterLAN systems on version 8.0.5 and above, such as New York State and Rockland County, can also communicate over the IPAWS-OPEN 3.0 communication network using CAP, EDXL-DE, EDXL-RM, and CMAS.31 Dutchess County, New York City (NYC), Nassau, and Suffolk use different versions of E Team. NC4s latest release of E Team version 9 allows users to customize the formats of resource messages, such as requests and responses, to be compatible with other systems on the receiving end.32 However, only the latest version 9 release of E Team, available since early 2011, provides this functionality, and it requires experienced information technology specialists and programmers to be properly configured.

30 Interview with Tom Rafferty, Emergency Management Section of the New Jersey State Police. 12 March 2010. 31 Interview with Patrick Cerra, Buffalo Computer Graphics, July 2012. 32 Interview with Erik Kant, NC4. 20 May 2010.

14

iNfOrmatiON SHariNG mEcHaNiSmS | COnfidential. FOr Official 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 from the local to the state level by leveraging the interoperable message module of DisasterLAN with the custom forms capabilities of E Team. NYC OEM has successfully exported a resource request report from E Team, wrapped it in Emergency Data Exchange Language Distribution Element (EDXL-DE) and posted it to the Integrated Public Alert Warning System (IPAWS); this is discussed in greater detail on p. 22 in the section titled, Implementing EDXL-RM in the Region. Once NYC OEM can convert the standard resource request into a valid EDXL-RM message, an end-to-end message exchange test will be conducted with New York State.33 Putnam County uses a customized IMS unique to its jurisdiction. This custom system runs on a SQL platform and is used to track the status of county and state emergency logistics operations using editable and non-editable timestamps. It also has the ability to track fire department, emergency medical service (EMS), and hospital availability, Indian Point emergency levels, and all traffic incidents, including details on who is assigned to the incident and the estimated time for clearing. While it has a mail module that allows tracked and recorded messages to be sent to other users of the same system, it does not currently have any data sharing or interoperability capabilities with other IMSs.34

Pennsylvania

The eight county-level agencies of the Northeast Pennsylvania Counter Terrorism Task Force (NEPACRTTF), the Southeastern Pennsylvania Regional Task Force (SEPARTF), and the Pennsylvania Emergency Management Agency (PEMA) have already developed specific operational linkages between their IMSs. PEMA recently decided to use KnowledgeCenter as its IMS, and will provide the same link that it has with NEPARCTTF & SEPARTF to all other county emergency management agencies within the Commonwealth. This capability will allow county-level users to automatically transmit resource requests to the Pennsylvania Emergency Management Agency (PEMA) EOC when they cannot be fulfilled at the county-level. This transmission is initiated by Knowledge Center users with a simple Yes to send the request to the state. If a user selects No they can still retrieve the request at any time and change the answer to send the request to the state. When a user selects to send the request to the state (Yes selection), the user sees a visual confirming successful transmission, date, time, resources specifically requested, and an ID reference.

33 Interview with Mark Frankel, NYC OEM June 2012. 34 Interview with Tom Lannon, Putnam County OEM. June 2012.
iNfOrmatiON SHariNG mEcHaNiSmS | COnfidential. FOr Official 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 agencys existing plans and procedures.35

State-to-State (EMAC)

At present, each of the four state Emergency Management Associations (EMA) in the Region uses a different IMS. As such, state-to-state Emergency Management Assistance Compact (EMAC) resource requests are usually transmitted along conventional pathways such as e-mail, phone and fax. The requestor will likely use the National Emergency Management Association (NEMA) Requisition A form. NEMA also maintains a state-to-state communications portal that can be used to track these requests, but it is not presently compatible with the Regions IMSs.36 If requests cannot be fulfilled at the state level, the state will submit an Action Request Form (ARF) to FEMA. The ARF is usually submitted electronically, as a .DOC or .PDF37 that has been attached to an e-mail, or is submitted as a hard copy. All ARFs must be signed by the state governor or their designee and the federal government only recognizes paper for this process at the moment. However, this process may change in the future once every FEMA region begins using WebEOC and is able to receive web-based electronic requests directly into that system. WebEOC is the IMS currently used at some jurisdictional level by 46 of the 50 states, and will be rolled out to all FEMA regions beginning in August 2012.38 FEMAs Logistics and Supply Chain Management System (LSCMS) is another resource management system modeled on 3PL and SCM best-practices that is used to fulfill orders and track resource requests, shipments and receipts. Once released, FEMAs LSCMS should boost the agencys capabilities for managing resources and will likely result in better tracking visibility and command and control of critical resources.39

Federal

35 Interview with Guy Miller, Monroe County PA OEM, and Dave Williams, PEMA. June 2012. 36 Interview with Captain Howard Butt, EMAC State Coordinator for New Jersey State Police. 24 March 2010. 37 Miguel Jaller and Jose Holguin-Veras. Immediate Resource Requirements After Hurricane Katrina: Policy Implications for Disaster Response. (Rensselaer Polytechnic Institute, 2010). 38 Interview with Jason Wind, FEMA Region II. 20 June, 2012. 39 Interview with Jason Wind, FEMA Region II. 20 June, 2012.

16

iNfOrmatiON SHariNG mEcHaNiSmS | COnfidential. FOr Official Use Only

Information Sharing Capabilities

This section highlights the current standards that are available and used for information sharing within the Region and among IMSs. Common Alerting Protocol (CAP)
All of the Regions 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: Interoperability: The CAP Alert Message should provide a means for interoperable exchange of alerts and notifications among all emergency information systems. Completeness: The CAP Alert Message format should provide for all the elements of an effective public warning message. Simple implementation: The design should not place undue burdens of complexity on technical implementers. Simple XML and portable structure: Although primary use of the CAP Alert Message is as an XML document, the format should be adaptable to other coding schemes. Multi-use format: One message schema supports multiple message types (alert, update, cancellations, acknowledgements, error messages) in various applications (actual, exercise, test, system message). Familiarity: The data elements and code values should be meaningful to warning originators and non-expert recipients alike. Interdisciplinary and international utility: The design should be applicable worldwide and allow for a broad range of public safety/emergency management applications.40

Emergency Data Exchange Language Distribution Element (EDXL-DE)

The primary goal of EDXL-DE is to serve as a container to facilitate the routing of properly formatted XML messages. The relationship between EDXL-DE and EDXL-RM is similar to the relationship between an envelope and the actual letter it contains. The EDXL-DE wraps the EDXL-RM content that would comprise the resource message and contains key routing information such as the name and address of the recipient and sender. The key principles of EDXL-DE include: Provide an Open Container Model to enable dissemination of one or more emergency messages. Provide flexible mechanisms to inform message routing and/or processing decisions. Enable dissemination of messages based on geographic delivery area. Enable use and re-use of data content and models developed by other initiatives. Support process-driven specific messaging needs across emergency professions. Support everyday events and incident preparedness, as well as disasters. Facilitate information sharing and data exchange among local, state, tribal, national and non-governmental organizations that provide emergency response services. Utilize a multi-use format so that one message schema supports multiple message types in various applications.41
40 http:/ /docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html. Accessed 7 June, 2012. 41 http:/ /www.oasis-open.org/committees/download.php/17227/EDXL-DE_Spec_v1.0.html. Accessed on 7 June 2012.
iNfOrmatiON SHariNG capaBilitiES | COnfidential. FOr Official Use Only

17

Use of Established Standards

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

Information Sharing Capabilities

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 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 reports Adapters for legacy systems 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 Official Use Only

DisasterLAN
x

E Team
x (Server Agnostic)

KnowledgeCenter
x

WebEOC
x

x x x x x x x x x x x x x x x x x 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 N/A x x x

x x x x x x x x x x x x x x x x x x x

iNfOrmatiON SHariNG capaBilitiES OVErViEW | COnfidential. FOr Official Use Only

19

Adopting EDXL-RM
The Emergency Data Exchange Language Resource Messaging (EDXL-RM) is a recognized messaging standard that can support the Regions existing resource management practices while expanding the capability for coordination between different jurisdictions, agencies, and levels of government.
In June 2010, the Regional Information Management Solution (RIMS) Planning Team agreed to recommend the EDXL-RM standard for adoption by the Region.42 The Planning Team generated consensus for a standards-based approach as the only viable way to address current interoperability problems and create new opportunities for resource management, resource request linking and field asset visibility.

EDXL-RM 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 and Compatibility (OIC) The Disaster Management Practitioner Steering Group (DM-PSG) EDXL-RM was adopted in 2008 by the Emergency Management Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS), a non-profit consortium for the development and adoption of open standards in public information sharing. EDXL-RM has also been registered and accepted as a National Information Exchange Model (NIEM) 2.0 Conformant Schema, making it the only publicly published data-sharing standard available to projects that require NIEM-compliance. NIEM-compliance is currently required by DHS and the US Department of Justice for interagency information exchange43 as well as for certain DHS grants for state and local projects. As a NIEM-conformant standard, EDXL-RM appears to be the only recognized standard for emergency management resource messaging in the United States and will be required for all recipients of federal grants for projects implementing XML-based information exchange.44

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

20

ADOptiNG EDXl-rm | COnfidential. FOr Official Use Only

The EDXL-RM standard message enables information sharing between resource consumers and resource suppliers, and can send and respond to the following requests: Requests for Information, such as determining if a state agency can supply a generator. Requests for Quotations, for linkages to agency procurement and accounting systems, such as determining and authorizing rental costs of a crane from a private vendor. Unsolicited Offers of Resources, such as offers of support from VOADs. Requests for Resources, such as formally procuring a generator from a state agency. Requisitions for Resources, for eventual linkages to agency procurement and accounting systems, such as issuing a purchase order to private vendor. Requests for Return of a Resource, such as a state agency requesting the return of a generator. Requests for Deployment Status, such as requests for GPS coordinates to update a resource request with the location status of a shipment that is in transit for delivery. Release a Resource for Deployment, such as issuing formal instructions to an agency or private vendor for delivery of a resource to an incident location or staging area. Requests to Extend Deployment Duration, such as requests to continue renting a resource from a private vendor when a need exists. These messages are standardized into 16 different schema, or standard message templates for data-sharing. The following figure shows the different message behaviors under EDXL-RM. Request Information Response to Request Information Request Quote Response to Request Quote Offer Unsolicited Resource

Discovery

RESOURCE CONSUMER

RESOURCE SUPPLIER

Request Resource

Ordering

RESOURCE CONSUMER

Response to Request Resource Requisition Resource Commit Resource

RESOURCE SUPPLIER

Deployment

RESOURCE CONSUMER

Request Return Response to Request Return Request Resource Deployment Status Report Resource Deployment Status Release Resource Request Extended Deployment Duration Response to Request Extended Deployment Duration

RESOURCE SUPPLIER

ADOptiNG EDXl-rm | COnfidential. FOr Official Use Only

21

Implementing EDXL-RM in the Region

This section examines possibilities for the Regions IMSs to become compliant to the EDXL-RM standard and how EDXL-RM messages can be shared between jurisdictions.
All the IMSs in the Region currently provide a method for interoperable data sharing that supports resource management and corresponding operational coordination. However, interoperability is not necessarily part of the off-the-shelf solution and may need to be designed around systems already in place. The Region should look into drawing upon interoperable data-sharing capabilities that support resource management. All of the IMSs in use in the Region can maintain an inventory of available resources and display a list of resource requests and status. The table below lists the tools and capabilities needed for each IMS to support resource management. Further details and sources are included on the following page.

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 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 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 mobilization and demobilization information. Tracking, Inventorying 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 jurisdictions 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 Validate and generate reimbursement claims for the proper authorities.

22

implEmENtiNG Edxl-rm iN tHE rEGiON | COnfidential. FOr Official Use Only

DisasterLAN
x N/A x x x x x x x x x x x x x x

E Team
x N/A x x x x x x x x x x x x x x

KnowledgeCenter
x N/A x x x x x x x x x x x x x

WebEOC
x N/A x x x x x x x x

x x

implEmENtiNG Edxl-rm iN tHE rEGiON | COnfidential. FOr Official Use Only

23

While each IMS has similar basic capabilities for operational coordination, they all have different means of supporting interoperability. In addition, each IMS supports the EDXL-RM standard in its own way.
E Team and DisasterLAN can maintain a database of suppliers (both public and private) to assist users in fulfilling resource requests. WebEOCs version 7 Professional comes with a standard Resources status board, which helps users maintain, manage, and assign inventory of available resources. KnowledgeCenters 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 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 Alerting Protocol (CAP) and EDXL-DE.45 The DisasterLAN interoperability module has also begun to introduce capabilities to send resource requests between different DisasterLAN users. ETeams 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 IMSs 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. The next steps are to convert the standard resource request into a valid EDXL-RM message.47 ESi offers an optional add-on, ESi WebFUSION, which allows WebEOC users to communicate with older versions of 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 Interoperable Messaging Module. BCG. Accessed from http:/ /www. buffalocomputergraphics.com/documents/interoperable-messaging.pdf on 2 April 2010. 46 Interview with Erik Kant, NC4. 20 May 2010. 47 Interview with Mark Frankel, NYC OEM, June 2012. 48 ESiWebFusion. ESi. Accessed from http:/ /www.esi911.com on 2 February 2010.

24

implEmENtiNG Edxl-rm iN tHE rEGiON | COnfidential. FOr Official Use Only

Establishing Regional Operational Coordination

Once the Regions IMSs are able to use EDXL-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 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 FEMAs 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 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 Teams decision; descriptions 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) was originally developed as part of FEMAs 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, up from approximately 67 percent in 2009. As part of the IPAWS 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 to share information in real-time across different software programs, systems, networks and devices, utilizing the following EDXL standards:51

49 Reviewed and approved by Neil Graves, IPAWS Engineering Branch. 18 June 2012. 50 FEMA National Preparedness Report May 3, 2012 https:/ /www.fema.gov/library/viewRecord. do?id=5914 51 FEMA. DM-OPEN Full Requirements. 19 February 2009.
EStaBliSHiNG rEGiONal OpEratiONal cOOrdiNatiON | COnfidential. FOr Official 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 were implemented in each agencys IMS there should be no impact to user operation within an agencys existing plans and 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 Regions IMSs appear fully engaged with IPAWS-OPEN so it is likely that information sharing capabilities within upcoming versions of the Regions IMSs will closely mirror those capabilities supported by IPAWS-OPEN. Like a courier service, IPAWS-OPEN will not read or validate the EDXL-RM content contained within the 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. If EDXL-RM messages are to be effective using IPAWSOPEN, an agencys IMS will need to interpret these messages appropriately, which they currently cannot do. Since 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, 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 after a catastrophe. However, since 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 platform for the Region, and represents a solid first step in a path forward that will lead to greater interoperability among the many agencies across the Region.
52 OASIS. Common Alerting Protocol, v. 1.1: Oasis Standard CAP-V1.1, October 2005. Accessed on 22 February 2010 from http:/ /www.oasis-open.org/committees/download.php/15135/emergencyCAPv1.1-Corrected_DOM.pdf 53 FEMA Disaster Management Program Open Platform for Emergency Networks. Instructions for Using the NOAA HazCollect Interface on the Open Platform for Emergency Networks (OPEN). 6 Nov 2008. Accessed on 28 February 2010 from http:/ /www.oasis-open.org/committees/download.php/31085/ using_hazcollect_on_open20081106.pdf 54 OASIS. Emergency Data Exchange Language Distribution Element, v. 10.: OASIS Standard EDXL-DE v1.0, 1 May 2006. Accessed on 22 February 2010 from http:/ /docs.oasis-open.org/emergency/edxl-de/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 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. 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 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, personnel and supply chain tools. Such a platform could have potential for enabling 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 Regions IMSs are engaged in the platforms development. Although both ESi and NC4 have downloaded the development kit from the UICDS site,57 it is not yet clear when any of the Regions vendors will commit to releasing 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, will also make implementation more complex. Agencies wishing to connect to multiple cores may find it difficult to interface with the framework effectively, and diversity in information security policies among many of the Regions 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 for their software 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. 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 data systems.
55 UICDS in Brief. [PowerPoint Presentation.] Accessed on 4 March 2010 from http:/ /www.uicds.us. 56 UICDS Overview for Technology Providers. Accessed on 4 March 2010 from http:/ /www.uicds.us. 57 E-mail from Chip Maloney, Principle Systems Engineer. 24 November 2009.
EStaBliSHiNG rEGiONal OpEratiONal cOOrdiNatiON | COnfidential. FOr Official Use Only

27

Appendix A
NIMSSupporting Technology Evaluation Project (STEP) The Federal Emergency Management Agency (FEMA) National Preparedness Directorate (NPD) offers the Supporting Technology Evaluation Project (STEP) to assist the response community with evaluation and testing of IMSs. This project evaluates and verifies interoperability of commercial and government software and hardware. Each IMS is evaluated to determine incorporation of:
NIMS concepts and principals Common Alerting Protocol (CAP) version 1.1 and 1.2 Integrated Public Alert Warning System (IPAWS) 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

NIMS-STEP Evaluations

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 elements and easily generates CAP compliant alert messages.59 E Team, KnowledgeCenter and WebEOC were not submitted for NIMS-STEP evaluation. NIMS-STEP evaluates a products 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:/ /www.ptaccenter.org/step/index 59 Results from each evaluation may be accessed at www.rkb.us (keyword STEP). Accessed June 2012

28

AppENdicES | COnfidential. FOr Official Use Only

Appendix B
Additional Research Commercial off the shelf (COTS) solutions that serve 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 platform to integrate data from different healthcare sources through a portal that can function as a IMS with an advanced GIS display. HIPPOCRATES is an impressive platform for managing health-care incidents while providing a common operating picture for state-level healthcare 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 constituents. Such areas include interoperability, standards-adoption, and data capabilities to support resource management / supply chain functionality. HIPPOCRATES is the only public solution researched for this paper that has considered the continuing proliferation of mobile devices and their potential to serve as effective data access-points for emergency response personnel. As a IMS, HIPPOCRATES has the ability to send data to mobile devices, though this ability has so far been limited to basic surveys for situational awareness. Additional information on the platform is available at https://hippocrates.nj.gov/

HIPPOCRATES

FATPOT: For all the People of the (World)

FATPOT Peer Intelligence Virtual Data Fusion Software is a commercial off-the-shelf middleware platform. The system is unique because it does 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 any one standard. Since there are at least four IMSs in use by the Region, this would greatly simplify the Regions path-forward for improved data-sharing. In theory, if FATPOT were implemented in each agencys 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, the tool is for sale by a private vendor. In addition, FATPOT would only integrate the current versions of the Regions IMSs. As such, if agencies upgrade or change their IMSs, they would also need to upgrade the FATPOT platform to ensure that it continues to pass these messages. FATPOT would be implemented with a centralized hub and spoke structure, where all messages are first sent to a central server where they are routed to the intended recipient. FATPOTs centralized platform can provide users with access to a virtual view of the Regions resources. Unlike a courier service, which would analyze only information on the messages envelope, the FATPOT system would analyze
AppENdicES | COnfidential. FOr Official Use Only

29

information within the message itself and translate it for the intended recipients IMS, using adapters, data mapping tables and data transformation services.60 FATPOT states that it can work as a data-sharing platform, regardless of system or vendor.61 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 IMS that FATPOT has specifically integrated is WebEOC.62 Additional information on the platform is available at http://www.fatpot.com

Thinkstream

Thinkstream differs from other 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. Thinkstreams incorporation of a common standard such as EDXL-RM ensure that the system can be crafted to be NIEM-conformant. Thinkstream is implemented using either an Enterprise Server Bus (ESB) or a Service Oriented 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, Thinkstream is for sale by a private vendor; as such, the financial implications of selecting this tool may differ from other freely-available middleware options such as IPAWS-OPEN and UICDS. However, while FATPOT would only integrate the current versions of the Regions IMSs, Thinkstream has worked with several emergency management projects in California to provide continuing interoperability between systems, despite upgrades that might alter internal datahandling procedures. Additional information on the platform is available at http://www.thinkstream.com

60 FATPOT Technologies LLC. FATPOT Peer Intelligence Virtual Data Fusion Software: An Interoperable Platform for Public Safety. 15 August 2007. 61 FATPOT Technologies LLC. Promotional Literature: Public Safety and Homeland Security Data Interoperability. Received at the 2nd Annual State Border Coordination Workshop, Gettysburg, PA. 26 January 2010. 62 Telephone call with Scott LeFevre of FATPOT Technologies 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 enterprise platform Depiction Real-time simulation and 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 Official Use Only

31

Appendix C
This section provides information on how to find additional information on issues discussed 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 Draft Errata (21 July 2009) http://docs.OASIS-open.org/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 Division Projects http://www.FEMA.gov/emergency/ipaws/projects.shtm#6 Supporting Information for UICDS UICDS: Unified Incident Command for Decision Support http://www.uicds.us

32

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. 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. Conventional Pathway: A mode of communication that does not rely on electronic data interchange (EDI) for sharing of information. These 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): A standard message distribution framework that serves as a container to route properly formatted XML messages. The EDXL-DE wraps the message and contains key routing 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. 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 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 organizations, and the private sector to work seamlessly to prevent, protect against, respond to, 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 Official Use Only

33

Schema: Standardized message formats for data sharing through XML. SQL (Sequel): A special purpose programming language designed for 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 3PL API ARDEC ARF BCG CAD CAP COG CONOPS COTS CMAS CT DEMHS DHS DM-PSG EAS EDI EDXL EDXL-DE EDXL-HAVE EDXL-RM EMA EMAC EMS EOC ESB ETL FATPOT FEMA GIS IMS IPAWS IPAWS-OPEN ICS

Definition Third-Party Logistics Application Programming Interface Armament Research Development and Engineering Center Action Request Form Buffalo Computer Graphics Computer-Aided Dispatch Common Alerting Protocol Collaborative Operations Group Concept of Operations Commercial Off-The-Shelf Solution Commercial Mobile Alert System Connecticut Department of Emergency Management and Homeland Security Department of Homeland Security Disaster Management Practitioner Steering Group Emergency Alert System Electronic Data Interchange Emergency Data Exchange Language Emergency Data Exchange Language Distribution Element Emergency Data Exchange Language Hospital Availability Exchange Emergency Data Exchange Language Resource Messaging Emergency Management Agency Emergency Management Assistance Compact Emergency Medical Services Emergency Operations Center Enterprise Service Bus Extract, Transform, Load For All The People Of The ("World") Federal Emergency Management Agency Geographic Information System Incident Management System Integrated Public Alert and Warning System Integrated Public Alert and Warning System Open Platform for Emergency Networks Incident Command System
REFERENCES | COnfidential. FOr Official Use Only

35

IT LAN LSCMS NEMA NEPARCTTF NIEM NIMS NIMS-STEP NJ DHSS NJ OEM NPD NWEM NWS NYC OCME NYC OEM NYS DHSES OASIS OCME OEM OIC PEMA RCPGP RCPT RIC RIMS ROIC RRMS SCM SEPARTF SOA SQL UICDS VOAD XML

Information Technology Local Area Network Logistics Supply Chain Management System National Emergency Management Association Northeast Pennsylvania Regional Counter Terrorism Task Force National Information Exchange Model National Incident Management System NIMS Supporting Technology Evaluation Program New Jersey Department of Health and Senior Services New Jersey Office of Emergency Management, New Jersey State Police National Preparedness Directorate Non-Weather Emergency Messages National Weather Service New York City Office of Chief Medical Examiner New York City Office of Emergency Management New York State Division of Homeland Security and Emergency Services Organization for the Advancement of Structured information Standards Office of Chief Medical Examiner Office of Emergency Management Office of Interoperability and Compatibility Pennsylvania Emergency Management Agency Regional Catastrophic Preparedness Grant Program Regional Catastrophic Planning Team Regional Integration Center Regional Information Management Solution Regional Operations Integration Center Regional Resource Management System Supply Chain Management Southeastern Pennsylvania Regional Task Force Service Oriented Architecture Structured Query Language Unified Incident Command and Decision Support Voluntary Organizations Active in Disaster Extensible Markup Language

36

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://www.buffalocomputergraphics.com/documents/DLAN%20Call%20Center%20 Slick.pdf Buffalo Computer Graphics. DisasterLAN Interoperability Messaging Module. Accessed May 16, 2012. http://www.buffalocomputergraphics.com/documents/interoperablemessaging.pdf Buffalo Computer Graphics. DisasterLAN Preplanning Module. Accessed May 16, 2012. http://www.buffalocomputergraphics.com/documents/DLAN%20Preplanning%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 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 Version 7. Accessed February, 2010. http://www.esi911. com. ESi. WebEOC Resource Manager. Accessed February, 2010. http://www.esi911.com. ESi. ESi WebFusion. Accessed February, 2010. http://www.esi911.com. FATPOT Technologies, LLC. FATPOT Peer Intelligence Virtual Data Fusion Software: An Interoperable Platform for Public Safety. August 15, 2007. FATPOT Technologies, LLC. Public Safety and Homeland Security Data Interoperability. 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. 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://www.fema.gov/library/viewRecord.do?id=5914 Federal Emergency Management Agency Disaster Management Program. Instructions for Using the NOAA. February 28, 2010. http://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 Official 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 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 Technologies, LLC. Interview January 11, 2010. 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. www.rkb.us (keyword STEP) NC4. ETeam Functionality. Accessed June 5, 2012. http://www.NC4.us/ETeam.php. New Jersey Department of Health and Senior Services. Hippocrates. https://hippocrates. nj.gov/. NIEM Program Management Office. NIEM Implementation Guidelines.Accessed June 10, 2012. http://www.niem.gov/implementationguide.php. OASIS. Common Alerting Protocol (CAP). Accessed June 7, 2012. 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.oasis-open.org/committees/download.php/17227/ EDXL-DE_Spec_v1.0.html OASIS. Emergency Data Exchange Language Resource Messaging (EDXL-RM). Accessed January 24, 2010. http://docs.oasis-open.org/emergency/edxl-rm/v1.0/ EDXL-RM-SPEC-V1.0.doc. Rafferty, Tom. New Jersey State Police. Interview May 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 Technology Evaluation Project. Accessed June 7, 2012. https://www.ptaccenter.org/step/index. Thinkstream. http://www.thinkstream.com. Unified Incident Command and Decision Support (UICDS). UICDS in 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://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
ARDEC ARDEC Connecticut Capitol Region Emergency Planning Committee CT DEMHS CT DEMHS CT DEMHS DHS Office of Emergency Communications DHS S&T Evolution Technologies, Inc. FEMA Region II FEMA Region II FEMA Region II MITRE Corporation Monmouth University Monmouth University Rapid Response Institute Monmouth University Rapid Response Institute Monroe County Monroe County Office of Emergency Services Morris County OEM New York City OCME New York City OEM New York City OEM New York City OEM New York City OEM New York City OEM New York City OEM New York City OEM

Name
Ekta Patel Aaron Lieb Carmine Centrella Robert Scata Bill Tessier John Gustafson Chris Tuttle Mitch Erickson Tim Grapes John Alonso Laura Swedlow Jason Wind Don McGarry Jim Hammil Bob Kelly Barbara Reagor Guy Miller Raymond Hayling Hassan Adekoya Erin Bores Daniel Casey Mark Frankel Henry Jackson Jonathan Jenkins Dennis Quinn Michael Schultz
REFERENCES | COnfidential. FOr Official Use Only

39

New York City OEM / Regional Logistics Program New York City OEM / Regional Logistics Program New York State DHSES New York State DHSES New York State DHSES New York State DHSES New York State DHSES NJ Department of Health and Senior Services NJ OHSP NJ OHSP NJ OHSP NJ OHSP NJ OHSP NJIT Business Force NJIT Emergency Management Business Continuity Program NJSP OEM Northampton County Emergency Management Services Regional Logistics Program Regional Logistics Program Regional Logistics Program Regional Logistics Program Regional Logistics Program Warren County OEM Warren County OEM Westchester County OEM Westchester County OEM For more information please contact:

Kiran Dhanji Alex Markowski Rick French David DeMatteo Nadine Macura Kevin Ross Jay Jobel Eileen Troutman Scott Costello Gene Haplea Brad Mason Jennifer Michalchuk Jon Morgan Col. Henry Straub Mike Chumer Tom Rafferty Bob Mateff Pearl Cheng Detgen Greeff Jim Penta Alexander Marks Sandra Woods Bill Hunt Frank Wheatley Dennis DelBorgo Noah Goldberg

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

40

REFERENCES | COnfidential. FOr Official Use Only

RE GI ON

TROPHIC PLA TAS NN CA IN AL

Produced by the Regional Logistics Program www.EmergencyLogistics.org

n Ne Pe wJ ut erse y Connectic

ns ylv an ia

AM TE

w Ne
rk Yo

APPENDIX D Sample Resource-Specific Data Collection Form

70

71

72

73

74

75