OpenHazus Research and Analysis.docx

OpenHazus Research and Analysis

Version 2.0 February 2, 2021

Prepared by the IBM Risk MAP CDS Team

Table of Contents

OpenHazus Research and Analysis February 2021

Page i

Executive Summary The goal of this document is to describe the current and future states of Hazus, FEMA’s nationally standardized methodology for estimating losses due to natural hazards. Hazus currently has an estimated 10,000 users globally and is widely respected for its peer-reviewed scientific methodology and multi-disciplinary approach to disaster preparedness. Since its inception in the 1990s, Hazus has continued to expand its advanced analysis capabilities for natural hazards, while making use of the latest desktop technology in viewing, analyzing, and presenting the results of modeled scenarios. If Hazus is to maintain its relevancy and credibility among disaster professionals, it must continue to take advantage of new technology, and new scientific methods for loss estimation. This paper will present an overview of existing Hazus technology and evaluate options for moving the current state to web-based, open source architecture.

It is important to note that Hazus, and subsequently, the proposed OpenHazus solution, is a highly complex set of tools which include academic hazard and engineering science, advanced computational methods, and a diverse collection of coding languages and technologies. This document outlines requirements and technology recommendations for OpenHazus. It is not intended as a technical design document, but it does encompass all of these components to present OpenHazus as a single, comprehensive system.

The following five categories of requirements have been proposed for OpenHazus through ongoing discussions with FEMA, Risk MAP CDS, and the user community: 1) Independence from desktop technology; 2) Independence from Esri ArcGIS products, with minimized dependence on GIS overall; 3) Modularization of existing Hazus capabilities, to streamline development and allow users to customize their experience; 4) Create data sharing opportunities for baseline FEMA datasets, third party authoritative data, and custom user data; and 5) Increase automation for common, baseline, or bundled analyses.

An Analysis of Alternatives (AoA) was performed on over 30 technology options to determine which would best meet the five requirements categorized above. Weighted evaluation factors were applied to over 100 sub-requirements across each of the technology options, with top recommendations identified for each category. An overall system architecture for open source modules within a web-based framework is also proposed, allowing for adaptability to structure the recommended technologies within the architecture as needed. A final recommendation is made for existing Hazus functionality and source code to be re-architected to open source modules according to the optimal technology for each function, then structured in a component MicroServices container environment. For some of the recommended technologies, proofs-of-concept (PoCs) are discussed to better inform future OpenHazus design sessions.

A number of next steps are proposed as a result of the AoA, architecture solution, and PoCs, including: 1) Conducting a working session with FEMA to determine the sensitivity of, and possible changes to, the weighting criteria used in the AoA; 2) Completing all proposed PoCs; 3) Phasing OpenHazus design to begin with inventory updates and flood methodology including a lightweight desktop utility for secure data users, the latter already in progress through the PoCs; 4) Beginning development and deployment of the loss modeling library to provide Hazus results to a broad online audience; and 5) Beginning to establish governance and policy for management of open source data and code.

Introduction Hazus is the standard loss estimation methodology program for natural hazards, used and published by the Federal Emergency Management Agency (FEMA). Since its inception in the 1990s, Hazus has provided stakeholders with a nationally standardized, peer-reviewed, and scientifically robust methodology for estimating potential natural hazard risks. Primary stakeholders include decision makers, such as state and local elected and appointed officials, who provide the leadership and resources to apply Hazus for risk assessment as well as practitioners like state and local emergency managers, planners, and floodplain managers, who are directly responsible for mitigation planning and other emergency management tasks. However, Hazus has faced many challenges as an academic program developed decades ago, and now must undergo a revitalization to remain relevant both from a scientific and technological perspective. This document outlines recommendations for a new OpenHazus platform, which should primarily be a web-based management system for open source Hazus components. It is important to note that Hazus, and subsequently, the proposed OpenHazus solution, is a highly complex set of tools which include academic hazard and engineering science, advanced computational methods, and a diverse collection of coding languages and technologies. This document outlines requirements and technology recommendations for OpenHazus. It is not intended as a technical design document, but it does encompass all of these components to present OpenHazus as a single, comprehensive system.

Purpose The purpose of this document is to define the functionality, interfaces, performance, attributes, and design constraints of OpenHazus, the proposed future of FEMA’s Hazus risk assessment software. The hypothetical end product of this effort has been coined “OpenHazus” to denote not only a programmatic shift to open source software and technology, but also a movement toward datasets, methodologies, and model functionalities that are more accessible and transparent for Hazus stakeholders. This document includes sections addressing current challenges, future requirements, architecture, technology evaluations, and prototyping.

Table 1: 2018 Hazus Program Goals

· Perform post-event studies comparing Hazus modeling against real world results to assess methodology accuracy

· Perform routine stakeholder analysis

· Draft a data management plan

· Coordinate supporting documentation and training materials with software releases

Intent This paper emphasizes key concepts being considered by the FEMA Hazus Program in preparation for a potential open source transition for Hazus. These concepts include identifying key motivations for redesigning Hazus in an open source, web-based framework, outlining baseline requirements for OpenHazus, and exploring available open source and web technologies for feasibility in OpenHazus architecture.

Background Hazus serves as one of the only freely available and technically accessible loss assessment tools for local, state, and regional planning officials. Hazus-based risk assessments serve as the backbone of local and state mitigation plans nationwide. However, for many users, the design and functionality of Hazus have become outdated as interest in risk information has widened and the technical landscape for data analysis has dramatically shifted. Planners and policymakers need risk information that is interpretable by a broad audience and delivered in efficient and universal data formats. Technical analysts and hazard specialists need risk modeling tools that are customizable and efficient with fully documented methodologies. While Hazus in its current form meets the minimum of these demands, an open source, web-based version of Hazus could meet these needs more fully and evolve more efficiently as new needs arise. This paper explores possible approaches and outcomes for an open source redesign of Hazus aimed at broadening its intent and better supporting its role as a leading publicly available risk modeling platform.

In an age of increasingly frequent and extreme weather events, applied researchers in a range of social and natural sciences are now dealing with the complexities of long-term planning, infrastructure protection, public health, and social vulnerability. This increased interest in quantitative hazard risk assessment has widened the use of academic communities working with Hazus and, in turn, increased the amount of expert input available for the continued improvement of Hazus modeling capabilities. However, the development of Hazus as centralized desktop software requires an update cycle structured to deliver periodic, costly releases. This approach does not support the efficient integration of new hazard and loss modeling methodologies proposed by hazard and risk researchers on a rolling basis.

An open source collection of independent analytical tools would dramatically decrease the resources required to implement methodological upgrades to Hazus and make it easier to solicit contributions from subject matter experts because they can now comment and improve upon methodologies that are available at source code level. This will build the end user’s confidence in Hazus results and increase the software’s accuracy. One of the main advantages of OpenHazus will be the establishment of a community of “power users” with development capabilities that, like in many Free and Open Source Software (FOSS) projects, handle some software support duties by participating in code maintenance activities on repositories like GitHub and bug tracking on forums like StackExchange. This community of expert contributors can act as a conduit between users and developers and efficiently extend Hazus development resources. This type of user is already active in the Hazus community, but is prevented from participating directly in Hazus development activities by the program’s closed source software release cycles. The increased transparency and accountability provided by a more significant web presence for Hazus development and deployment should improve stakeholder confidence significantly, and would align FEMA’s Hazus Program with the broader initiative to shift DHS applications to cloud technologies, as announced by the DHS Chief Information Officer in May 2018.

Since the Disaster Mitigation Act of 2000 (DMA 2000), demand for quantitative risk information has increased alongside a widening user base, evident in new regulatory and non-regulatory risk products delivered by the Risk MAP program and incentives offered by FEMA programs for communities or projects that implement data-driven decision making towards the reduction of risk (Manage Floodplain Risk | FEMA.gov). However, the Hazus Program has not effectively distinguished between non-technical users who benefit primarily from the risk information offered by Hazus results and technical users who benefit primarily from the ability to run Hazus analytical models. An open source redesign of Hazus should seek to better meet the separate needs of these different user communities. OpenHazus will have a single online resource where planners, project managers, and policymakers can access summarized risk data produced by past Hazus studies at varying geographic levels nationwide. This online portal will make Hazus results for probabilistic and deterministic scenarios as well as historic events discoverable and downloadable for all hazard models, with updates scheduled at a set frequency, thereby considerably widening the user base of Hazus. Standardized, user-tested visualizations for results will allow complicated technical model outputs to be easily digestible and better understood by the end user, bridging the gap between risk analysts and decision makers. Redirecting non-technical users toward a more immediately useful risk assessment resource will allow for the decentralization of Hazus analytical capabilities on a separate (but connected) platform geared toward more experienced data analysts.

As the audience and demand for quantitative risk information have grown, the technical infrastructure available to derive such information has drastically changed. Cloud computing capabilities have become standard, data visualization tools are numerous and designed for non-technical users, and traditional GIS tasks are increasingly integrated into generalized analytical workflows with fewer distinctions between spatial and non-spatial processes. Hazus dependency on Esri software was initially an advantage for Hazus because the majority of technically well-versed users had GIS experience and Esri’s ArcGIS Desktop platform has been the most widely used GIS in the United States for many years. However, as the community of stakeholders working with spatial data spreads beyond traditional GIS users, the need arises for visualization and analysis tools that effectively integrate spatial and non-spatial data in systems that are agile, accessible, and transparent – regardless of their interface.

A 2018 inventory found that the majority of Hazus code does not employ geospatial analysis. In fact, the earthquake and hurricane models (unless combined with tsunami or coastal flood) do not make calls to any Esri geoprocessing tools. While maps are a highly efficient tool for communicating natural hazard risk information, a large fraction of Hazus model results are more effectively communicated through traditional visualization techniques or their modern interactive counterparts (charts, graphs, infographics, etc.). The tight coupling of Hazus with ArcGIS Desktop places a significant burden on users who want to customize the software and extend its capabilities, and on the Hazus Program itself, whose resources are largely spent on cumbersome software releases that employ complex code changes to address otherwise straightforward functionality upgrades. Hazus is so tightly integrated with the dynamic link libraries of ArcGIS Desktop that a switch to ArcGIS Pro would require a complete rewrite of Hazus.

If GIS capabilities represent a small and burdensome fraction of Hazus functionality, it becomes practical to leverage available open source geospatial libraries to accomplish spatial data visualization and analysis, rather than designing all Hazus capabilities around a GIS interface. In addition to decreasing development costs and increasing customizability of Hazus methods, reducing the role of geospatial processing will substantially improve runtimes because Hazus will leverage the increased capabilities of large, tabular lookup tables and stored, pre-computed damage factors. Similarly, a relatively small percentage of Hazus users require a desktop environment for their risk modeling projects. Users with a legal obligation to maintain secure risk modeling data inputs in a desktop environment (actuaries, certain military planners, etc.) represent an estimated 5% of Hazus use cases. Although FEMA has yet to develop a cloud environment capable of hosting, processing and exchanging large amounts of public data in a variety of formats, DHS has announced an intended shift in computing technologies away from local environments and onto cloud resources.

Transitioning Hazus to a web-based architecture could fulfill 95% of user needs while increasing modeling speed and access and radically expanding the transparency of model methodologies, data, and results. Leveraging increased storage capabilities on the cloud and increased processing speeds of web servers will also eliminate current constraints on desktop inventory database sizes, including the requirement to use aggregated Census Tract or Block data. A key objective of the OpenHazus initiative is to provide nationwide site-specific risk analysis as a default capability, which will significantly increase the accuracy of FEMA loss estimates and more effectively communicate risk and vulnerability in order to drive cost-effective mitigation strategies. OpenHazus will have an easily searchable online repository for users to share local structure data, best practices, and risk assessment results. This requires the development of a quality control process to vet new data in collaboration with within FEMA and among FEMA partners.

OpenHazus has been conceptualized as a toolbox of multi-hazard methodologies that may, but do not have to, use GIS, to visualize the spatial distribution of risk to given assets. Removing the dependency not only on Esri GIS software but also on traditional GIS architecture, in general, can significantly broaden the range of potential OpenHazus users. Hazus users and developers would benefit from two different aspects of the proposed “toolbox” of open software architecture. In a highly modularized system leveraging as-needed open source analytical libraries, each tool is well documented and can be accessed individually. Users can employ only those Hazus modules that make sense for their projects, and developers can more efficiently expand and update Hazus functionality by accessing and updating separate analytical modules rather than editing a large, rigid and interdependent workflow. For example, researchers developing tsunami casualty estimation methods that consider debris paths can incorporate this added functionality into an extended version of the existing Hazus tsunami casualty module.

OpenHazus will also be designed to seamlessly integrate hazard inputs from authoritative federal agencies, including latest state-of-the-art flood, earthquake, hurricane, and tsunami hazard models. This will increase the quality of risk analysis results and eliminate the need for hazard modeling capabilities to be embedded within Hazus. These embedded processes have proven costly to maintain and consistently lag behind the latest available hazard modeling techniques.

Another beneficial aspect of an open architecture is the reliance on FOSS, which would make it easier to customize Hazus according to user needs for specific risk assessment projects. As advanced users develop customized versions of Hazus analytical processes, the Hazus Program can devote more resources toward collaborating with these users to review new model versions and integrate them into the official Hazus architecture, thereby leveraging the largely untapped expertise of the nationwide risk modeling community. A transition to FOSS would also increase the much-requested transparency of data and methods relied upon by federal agencies, allowing OpenHazus users to access key aspects of risk model architecture, thereby increasing trust in model outcomes. For example, the Oregon Department of Geology and Mining Industries (DOGAMI) published a Python-based extension of the Hazus flood module in 2018 that allows users to more easily customize damage functions for all structures in their analysis and quickly derive economic loss and recovery time for multiple flood hazard inputs. An open source architecture for Hazus will facilitate greater direct collaboration between the Hazus Program and partners like DOGAMI to incorporate new methods based on vetted external research projects. A transition to FOSS would also increase the much-requested transparency of data and methods relied upon by federal agencies, allowing OpenHazus users to access key aspects of risk model architecture, thereby increasing trust in model outcomes.

The next steps for OpenHazus include a phased development built around a modular architecture of Hazus analytical capabilities, as described in the remainder of the document.

Document Conventions See Appendix A for a Glossary of Terms used in this document. The term “Hazus” refers to the FEMA program and methodologies, and may include both legacy software versions and future proposed solutions. “Legacy Hazus” is used to describe the current desktop Hazus application. “OpenHazus” refers to the solution being proposed in this document. It should be noted that from Hazus’ inception in the 1990s through 2013, the name of the software was written as an acronym (HAZUS-MH). This notation is no longer in use by FEMA and should only be used if directly quoting a document from before 2013.

Intended Audience and Reading Suggestions This paper was written for review by members of FEMA’s Risk Management Directorate, including the Actuarial and Catastrophic Modeling Branch, the National Flood Insurance Program, the Engineering Services Division, and others, and certain portions may be of interest to members of the Hazus, risk assessment, hazard science, and mitigation planning professional communities. The proposed integration and reliance on authoritative hazard data products will be of special interest to other federal agencies

Overall Description This section describes the existing Hazus product, including the original context for development, ongoing challenges, and the current user community.

Product Perspective Hazus is a software suite within the Risk Mapping, Assessment and Planning Program (Risk MAP) of the Federal Insurance and Mitigation Administration (FIMA) of the Federal Emergency Management Agency (FEMA), which is one of over 20 component agencies of the Department of Homeland Security (DHS). Hazus provides a cost-effective method for quantifying potential social, economic, building and building losses resulting from given hazard information for earthquakes, floods, tsunamis and hurricanes. Hazus results allow users to develop policies that aim to decrease the risk of future loss due to natural hazards – a capability required by risk reduction policies developed SLTT. The overall objective of the existing Hazus program is to implement a nationally applicable set of standardized multi-hazard methodologies for estimating potential hurricane, flood, tsunami and earthquake losses on both structure-specific and regional scales.

When combined with detailed analyses and expert knowledge, the default datasets and model parameters included with Hazus provide an effective risk assessment tool. Depending on the availability of reliable hazard and inventory data for a given region or disaster, Hazus results can be used to assess damages immediately following a real event, drive planning activities for catastrophic scenarios, or inform mitigation initiatives at the community, state, regional or national level. Hazus is also used in support of DMA 2000 to develop the Risk Assessment portion of Hazard Mitigation Plans.

Subject matter experts from leading scientific, engineering, and academic communities collaborate with Hazus program staff to develop analytical capabilities for each hazard, improve the accuracy and software speed of existing Hazus tools, expand model functionalities, and foster community involvement from risk management professionals. Hazus provides the integrated multi-hazard loss estimation capabilities, varied according to user needs, hazard analyzed, and data availability. To provide flexibility, losses are estimated based on the accuracy of input data (Figure 1). Basic analyses (“Level 1”) are based on default inventory data aggregated at census geographies and parameter data provided within Hazus. Advanced analyses (“Level 2” and “Level 3”) are based on more accurate, user-supplied data for hazard, structure or damage parameter inputs. The appropriate level of analysis must be determined to meet the needs and resources of the user.

Hazus is distributed free of charge. However, it is designed to run as an extension to the commercial GIS software ArcGIS Desktop, developed and distributed by Esri, Inc. This software can be cost-prohibitive for many potential users. Esri is phasing out its development of ArcGIS Desktop in favor of a more modern architecture called ArcGIS Pro. Hazus is so tightly integrated with the dynamic link libraries of ArcGIS Desktop that a switch to ArcGIS Pro would require a complete rewrite of Hazus. While there are other reasons to pursue “open” solutions, the significant impending cost of rewriting Hazus to maintain compatibility with ArcGIS Pro has precipitated the need to redesign Hazus independent of external GIS software packages, which provides an opportunity to identify key obstacles preventing Hazus from effectively meeting the needs of users and to revisit Hazus requirements.

Figure 1: Legacy Hazus Usage Levels

Product Features Table 2: Legacy Hazus Product Features

Earthquake Ground Shaking Ground Failure Flood Frequency | Depth Riverine | Coastal Surge Hurricane Wind | Surge Tsunami Depth | Momentum Flux | Runup | Velocity

Inputs

ü

Direct Damage

Induced Damage

Direct Losses

Agricultural ü

ü

Product Challenges Because of its current architecture and software dependencies, Legacy Hazus faces a number of challenges. These are categorized below based on user observation, help desk reports, and tester feedback.

Desktop Architecture Users must download and install Hazus in a desktop environment. Hazus software development and release cycles take place every year and accomplish a pre-established set of tasks requested by FEMA.

· Release cycles cannot accommodate ad-hoc methodology improvements discovered year-round through engagement with researchers and risk management professionals. Risk assessment technology and methods evolve at a much faster rate than Hazus software, leaving Hazus continually behind what is considered state-of-the-art in risk analysis.

· Release cycles cannot accommodate real-time bug fixes.

· Installation of Hazus releases is a cumbersome process for users that can take hours depending on security permissions and at worst days if issues persist.

· High version dependency between Hazus and other desktop products (ESRI ArcGIS, SQL Server, and Windows OS) makes installation difficult for users and development costly for the Hazus Program.

· Hazus model processing speeds are dictated by user desktop hardware capabilities.

· The storage of large input datasets and Hazus results on local machines discourages efficient sharing among users and between users and the Hazus Program, contributing to a lack of transparency and accessibility in the Hazus community.

Designing OpenHazus to be independent of desktop software would drastically reduce development costs; eliminate complications with user desktop installs, increase processing power and associated analytical capabilities, and increase transparency and accessibility of model data, methods, and results.

User Input There is no structured system by which users can recommend model improvements, submit customizations, or share results from successful Hazus projects. User input is incorporated into Hazus Program activities through ad-hoc connections made between Hazus Program staff and the user community. Hazus result data are produced in formats that are either GIS-specific or stored in databases that are difficult for users to access.

· Customized or improved analytical processes or datasets are not effectively incorporated into Hazus software.

· Hazus project results are not effectively shared among the user community.

· Hazus user community efforts remain siloed instead of collective, risk assessment efforts are often duplicated, and decision-makers remain largely unaware of Hazus capabilities.

User Categorization Hazus users have been categorized primarily according to the “level” of analysis they perform (basic or advanced), encouraging a broad base of risk management professionals to be trained to perform basic Hazus analyses, while more technically experienced users are trained for advanced analyses.

· Significant resources are spent providing Hazus model training for non-technical members of the risk management community who are more interested in applying and communicating Hazus results than deriving them.

· The subsets of Hazus users who primarily need to interpret, apply, and communicate Hazus loss estimates (rather than generate them) are not specifically targeted by Hazus Program activities.

· Hazus results are presented in a way that can lead to misinterpretation by users without proper training Credibility Management Hazus source code is developed based on transparent engagement with the academic community through technical advisory committees, long-running partnerships with federal agencies, and consistent engagement with expert members of the risk modeling community in order to ensure state-of-the-art methodology. However, Hazus source code is not accessible by users and the provenance of Hazus model results generated by the user community is not centrally tracked.

· Users cannot verify for themselves the accuracy of Hazus model results.

· Users cannot easily distinguish between authoritative and erroneous Hazus results.

Incorrect, misinterpreted or out-of-context Hazus results are often circulated among the risk management community, which erodes Hazus Program credibility GIS Dependence The traditional GIS architecture of Hazus obscures the technically complex processes of hazard risk modeling behind a map interface. Users with GIS specializations are expected to undertake risk assessment projects that require professional or academic expertise in engineering, earthquake physics, structural dynamics, and advanced statistics, while experts in these areas without GIS skills are prohibited from leveraging Hazus for their risk modeling projects. As data analysis skill sets become more common throughout disaster-related disciplines, the risk modeling community has grown to include those who are interested in estimating hazard impacts but are unfamiliar with traditional GIS technology. The reliance of Hazus on desktop GIS software alienates these potential users. A more agnostic risk modeling platform – one that seamlessly incorporates both spatial and non-spatial components – would address the needs of a much broader user base.

A small fraction of current Hazus analytical processes are uniquely geospatial. These include traditional desktop GIS functions for clipping, mapping, projecting, and developing flood-related rasters. Geoprocessing steps dedicated to developing flood hazard data will be eliminated by the OpenHazus emphasis on external authoritative hazard datasets as model inputs. Aside from these geospatial analysis functions, the primary role of desktop GIS software in Hazus is the spatial visualization of data inputs (inventory, hazard) and model results (losses). As spatial and non-spatial data analytics become increasingly integrated, mapping functionality is more logically provided to users under a larger umbrella of data reporting tools. The relatively simple geospatial analysis and map functions required by Hazus can be easily replaced by open source geospatial libraries (Fiona, shapely, gdal, javascript, plotly, etc.) that meet these needs independent from a traditional desktop GIS architecture, and can more easily evolve along with geospatial technologies.

Flood Hazard Generation The lack of sufficiently detailed flood hazard data nationwide has created a significant gap in probabilistic flood risk that no authoritative agency has yet filled. Hazus developed an internal flood depth grid generation tool in order to partially fill this gap. This capability leverages simplified hydrologic analysis to derive a rough estimate of flood depths in gridded form. Hazus loss estimation based on these internally generated depth grids have been shown to have low accuracy, which has eroded trust in Hazus as a credible flood risk analysis tool. Hazus internal flood hazard generation processes are also computationally intensive and exceedingly slow to complete, which, when combined with their inaccuracy, results in significant user dissatisfaction. Computational requirements for flood hazard generation pose a singular restraint on Hazus processing speed, since the remaining steps in a risk analysis – identifying hazard severity at inventory locations, damage, loss, and impact estimation, as well as the generation of report elements that are simple tabular calculations handled easily by lightweight desktop utilities or web services.

Outdated and Generalized Inventory Data A significant obstacle to a more widespread use of Hazus is the amount of effort it takes to create inventory data. Developing the high-quality data required for an accurate and applicable risk assessment is without question the costliest part of performing a risk study, and often cost-prohibitive. FEMA has developed an incomparable resource of some 16 GB of generalized inventory data that are editable through the custom-designed Comprehensive Data Management System (CDMS). While these data could be a good starting point for authorities who do not have the personnel resources to develop their own inventories, they are provided only as backend SQL SERVER tables during routine Hazus installation and are not accessible to average users for custom analysis or visualization. Furthermore, demands for accurate risk information and targeted risk reduction have outgrown census tract-level analyses and with the availability of free building-level data, expectations have grown for FEMA to leverage a centralized national building data set for risk assessment.

Hazus contains baseline essential facility inventories for the U.S. provided in downloadable State databases in SQL SERVER format that will soon be sourced from the Homeland Infrastructure Foundation Level Data (HIFLD) program. These baseline inventories provide the user an out of the box capability to run Hazus analyses anywhere in the U.S. However, updating these static data and disseminating to users is a lengthy manual process, so many of the facility layers in Hazus have not been updated since they were developed in 2001.

Hazus demographic data updates are also completed manually, following decennial census releases. However, agencies like the Census Bureau provide dynamic data feeds through web Application Programming Interfaces (APIs) that would ensure constantly up-to-date demographic information, provided that the Hazus program maintains consistent collaboration with external agencies serving authoritative datasets necessary for accurate risk assessment.

User Classes and Characteristics Hazus user classes were differentiated based on frequency of use, subset of Hazus functions used, technical expertise, and experience according to standard practices for user classification in IT system. It is important to capture these user classes and characteristics to ensure any future implementation of Hazus accurately captures the breadth of Hazus requirements across its broad and diverse user communities, and the description of ways in which users engage with the software is a standard practice for the initial phases of any software redesign. Please see Appendix B for full use cases based on user type.

The Hazus user community is large and diverse, with an estimated 10,000 users globally according to a internal program survey completed in 2013. As FEMA’s standardized method for estimating damage and loss due to natural disasters, the intended audience initially for Hazus was emergency managers who work in mitigation planning. However, as indicated in previous sections, the wide range of functionality available within Hazus makes it a useful tool for many other sectors and industries both within and outside of emergency management. More recent surveys of the user community have found that nearly all attendees at FEMA-certified training events come from an emergency management job role, whereas a separate survey of Help Desk tickets found that Hazus users seeking assistance through the Help Desk are almost evenly distributed across job categories, sectors of emergency management, and even usage level within the software functionality. See Table3 for examples of job categories and sectors.

Table 3 shows possible user categorizations and sub-categories, which may be overlapping and cyclical according to where the user works, their specific job roles as related to Hazus, and training received in GIS or SQL SERVER platforms. See Appendix B for user profiles, developed according to industry standards for use cases. The user profiles in Appendix B provide notional examples of different Hazus users and demonstrate how one users can map to multiple user categories simultaneously.

OpenHazus provides an opportunity to rethink the classification of Hazus users in light of their overlapping and shifting roles. If baseline Hazus model results are provided in a user-friendly online platform, users seeking only these results will be able to view and download them without running their own analysis, as is currently required in Legacy Hazus. OpenHazus analytical modules can remain for users still requiring customizations, either in damage functions, inventory data, or hazard data specific to a scenario or community. OpenHazus will be specifically designed to accommodate this flexibility.

Table 3: Possible User Categorizations

3: Imports Level 2 data, plus reviews and modifies engineering/damage parameters

Government Contractor

Private Sector

Academic

International

User Documentation Comprehensive documentation, including User Manuals and methodology documentation (Technical Manuals) are available at: Hazus User & Technical Manuals | FEMA.gov. Please note, online documentation varies in age and relevancy. For up-to-date documentation on known bugs or discrepancies between documented methodology and Hazus source code, please see the User Release Notes specific to each release, also available at the link. Training videos are currently in process for being posted publicly to the FEMA YouTube channel and fema.gov.

Assumptions and Dependencies Challenges with Hazus in its current form have been discussed in this section; moving forward, this document will address OpenHazus requirements and recommendations for addressing these user needs and existing challenges. The following assumptions are made when discussing these options:

Hazus is a loss estimation tool. This is the core application of OpenHazus that takes precedence over other potential demands in supporting the mission of FEMA in general and of the Risk MAP program in particular. Any rewrite of Hazus will have to fulfill its current set of capabilities related to the estimation of social (fatalities, displacement and injuries), infrastructure, building, and economic losses due to natural hazards. OpenHazus implementation will emphasize the use of external, authoritative hazard datasets.

Hazus is free for users. OpenHazus as a methodology toolset shall remain free, as should access to core national datasets. OpenHazus server traffic can potentially be prioritized according to user types, such that users with secure data requirements have additional levels of security, or users in active response situations with time-sensitive analysis requirements can receive priority.

Hazus is publicly available. Hazus methodology and data shall continue to be publicly available in the form of accessible download files, user manuals, technical manuals, and analytical code.

System Features The following section describes high-level requirements for OpenHazus. These were derived first from a brainstorming session held in November 2018 between Risk MAP CDS and FEMA. The features identified from this initial session were further refined into categories, and then itemized within each category to provide input to an Analysis of Alternatives (AoA). The Boulder features and detailed category breakdowns are provided in this section, with the itemized requirements listed in Appendix C. Each category listed below the Boulder features provides a brief description for how the categorized items were weighted in the AoA tables. The weighting is based on a scale of 0 to 100, with a weighting of 100 defined as a necessary feature.

Boulder Features In November 2018, the Hazus Team met in Boulder, Colorado to outline the System Features envisioned for OpenHazus. A set of eight objectives for a hypothetical OpenHazus system were established at this meeting:

④ User-friendly GUI. The current user interface is an extension of GIS desktop software. With its separation from GIS, the OpenHazus user experience can be improved significantly with expanded options for interactive data visualization. Whereas Hazus was always conceived as a desktop (workstation) software, OpenHazus should be flexible enough to serve stakeholders in a web-based, desktop-based, and even mobile environment. Not all functions will be available in all environments, but the transition should be seamless from a UI/UX perspective.

⑧ Ability to automate workflows. A number of model runs can take quite a while to execute, especially if users want to run an ensemble of scenarios. It is therefore desirable to have the ability to run complete workflows in batch mode without any user interaction.

Desktop Independence Critical to OpenHazus is maintaining the existing functionality while expanding into a 21st century computing environment. The inventory data, as well as the Risk MPA flood hazard data holdings in the MIP and MSC, should now be directly accessible for any visualization, analysis and reporting function of OpenHazus, and have therefore been given the level of a necessity (Weight of 100, see Appendix E). Not absolutely necessary, but highly desirable, are password-protected repositories of user-defined inventory data and access to authoritative input data for hurricanes, earthquakes, and tsunamis (weights of 80-90, see Appendix E).