APPENDIX S — WEB-BASED REGISTRY APPENDIX S — WEB-BASED REGISTRY Web Portals To be effective for eRating, the elevation registry will need to have a web portal — a starting place on the Map Service Center's web site — with interfaces for input of data to the registry's database, and output of information needed for eRating. In addition to insurance agents and WYO companies, this portal should also be available to others involved in the NFIP, e.g., real estate agents (see CRS Section 340 that encourages real estate agents to disclose flood risk and the need for flood insurance to potential buyers), as well as the general public who should not need to submit a Freedom of Information Act request to obtain flood risk information for individual structures (see CRS Section 310 that encourages the availability of flood risk information on a public website). The interface should be designed with the users in mind while the underlying processes should be designed with the data sources in mind. To analyze potential options, the strategies will be categorized by the number of structures each strategy will have per transaction, and the type of user involved. At a fundamental level, any system consists of three major components: input, process, and output. This section will focus on the input and output controls and access portals within the elevation registry system (See Figure S.1). Input Process Output Figure S.1 — Elevation Registry System Components. In a significant number of systems these two highlighted components tend to be the most neglected because sufficient information about user requirements is never collected. To fully develop these components within the eRating system, full user requirements analysis will have to be performed before design and development of the system. Although the foundation of the system will be the data sources, the elevation registry system intended for eRating will be designed around user needs. Given the differing skill levels and needs of each user group, to ensure continued use of the system, all user types must be identified upfront and provisions made to accommodate their specific needs. Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY Elevation Registry — Phased Implementation The system should be implemented in two phases: the ramp-up phase, and the maintenance phase. During the initial ramp-up phase, data will be loaded through back-end portals available to the developers only, with no public access. Back-end portals are managed by the system administrator who controls the database and ensures it is not corrupted. Front-end portals are the "face" the user sees at the web portal, e.g., drop-down menus and other features that need to be user friendly so that users can interact efficiently with the web portal. During the second phase, information will be available for use by insurance agents and others, and data will primarily be loaded through front-end portals, with some back-end uploads for mass data inputs such as subsequent batch processing of remote sensing data. The data collected for each strategy can be loaded into the system during one or both phases of implementation, depending on the availability of the data. For example, existing EC data (Strategy A) will be primarily loaded during the initial ramp-up phase, whereas remote sensing data (Strategy B) will be uploaded during both phases, depending on when the data is ready and validated. Follow-on ECs generated individually by surveyors (Strategy D) will be loaded during the maintenance phase. Phase I - Ramp-up Phase II - Maintenance Input Portals Only Input & Output Portals Registry Data Base Back-end Portals Strategy A - Existing ECs Strategy B - Remote Sensing Strategy E - Alternative Data Sources Registry Data Base Back-end Portals Strategy B - Remote Sensing Strategy E - Alternative Data Sources Front-end Portals Strategy D - GPS surveys (New ECs) Public Users (Insurance) FEMA & Contractors Figure S.2 — Implementation Phases and Data Access. The major distinctions between front-end and back-end portals are the level of controls, or restrictions, enforced and access to data on users. Back-end portals will generally have fewer restrictions and the developers will be able to access specific data directly, including historical data. Figure S.2 illustrates how the strategies and the input/output functionalities will be integrated with each phase. Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY Phase I – Ramp-Up As noted above, during the initial ramp-up phase, data will be loaded into the elevation registry through back-end portals only. This will primarily take place by bulk loading of data from existing data sources that have been validated and processed for entry into the registry. This would include data acquired through Strategies A and E as well as remote sensing data acquired through Strategy B. Existing Elevation Certificates will be compiled and processed for loading into the elevation registry. These will include those ECs already in a database format as well as ones that need to be scanned and digitized and those that need to be digitized from existing scans. As outlined in Part I of this report under Strategy A, the potential sources of existing ECs include the following: • LOMA 2000: 91,600 database records • ISO data: 50,000 database records • Dewberry & URS: 16,381 database records + 3,119 hardcopy ECs • USACE: 1,200 database records • Communities: up to 1,000,000 hardcopy ECs Most of these ECs and records either have no latitude/longitude values, or their values are estimated by some form of automated geocoding. Furthermore, most of the ISO and community ECs and LOMA 2000 records have quality issues discussed above and would potentially be of lesser value to the registry. Nevertheless, Strategy A recognizes that some of the existing EC data will be of lesser value than EC data from other sources. Data from other FEMA databases will also be processed and loaded into the registry during Phase I. As noted in Strategy E, NEMIS and BureauNet are the two existing FEMA databases that contain data most relevant to the registry. • NEMIS Database. In FY 1999, FEMA deployed the National Emergency Management Information System (NEMIS) which serves as the information technology standard for the agency's Presidential disaster operations. During the transition to NEMIS, the data in ADAMS, the predecessor system, was transferred to the newer system. NEMIS automates federal disaster programs including incident activities, preliminary damage assessment, declaration processing, human services, infrastructure support, mitigation, and associated administrative and financial processing. During FY 2002, NEMIS supported more than 197 disasters, 42 of which were Presidential declarations. Currently, NEMIS contains information on over 400,000 structures, including a structure’s address, type (basement, no basement), and UTM coordinates (latitude and longitude). Given the complexity of NEMIS, it is more cost effective to load NEMIS data into the elevation registry in order to display Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY NEMIS data with other data needed for eRating, and neither export data to NEMIS nor require damage inspectors to enter data into the elevation registry directly. • BureauNet. BureauNet, or Policy-In-Force, is the reporting and user interface for the policy subsystem of an IBM mainframe database maintained by FEMA (other subsystems include claims and structures that can not be insured). The mainframe database includes historical policy data starting in 1974 and is updated by various sources including WYO companies. There are currently 4.5 million active policies (note: one active policy per structure) which include such information as date of construction, LAG, HAG, lowest floor elevation, geo-referenced coordinates, and policyholder information. FEMA’s NextGen project is in the process of updating the system to an Oracle database environment and revamping the analysis tools and policy rating engine. This database should be key for initial population of the registry. Given the diverse addressing protocols and requirements within the various databases, it is essential that the elevation registry adopt an addressing convention that is applicable universally. As discussed in Strategy B, remote sensing data that would support the registry include the following: • Photogrammetry equivalent to 2 ft contours, combined with on-site measurements; • LIDAR equivalent to 2 ft contours, combined with on-site measurements; and • LIDAR LAG/HAG elevations only for an entire community or county which could be processed to extract EC data such as the LAG and HAG for all structures in the community. These data would be batch loaded into the registry through a back-end portal. Remote sensing data collected before or after the implementation of the elevation registry will be processed similarly. Before any data can be posted to the elevation registry, it will have to be quality reviewed for accuracy (in accordance with one of the Options listed below) and certified according to FEMA standards. The process of certification will depend on several factors including collection technique, local needs, and FEMA partnerships with other agencies. After certification, data will be posted to the registry by FEMA or a FEMA cooperating technical partner (CTP) or contractor using. Phase II – Maintenance During the second phase, information will be available for use by insurance agents and others, and data will primarily be loaded through front-end portals, with some back-end uploads for mass data inputs such as subsequent batch Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY processing of remote sensing data or scheduled batch updates from existing databases. After the ramp-up phase, surveyors will be encouraged to use the front-end portal of the registry to prepare new ECs. During a typical year, thousands of structures are surveyed using GPS or conventional methods. The information is primarily recorded on a paper EC, certified by a surveyor, and given to the owner. The information may also be compiled by local government agencies. However, no national repository currently exists to compile the elevation information for surveyed structures, and this is the deficiency that would be solved through on-line entry of new ECs into the elevation registry. As part of FEMA's outreach program, surveyors and government agencies will be encouraged to use the elevation registry's web portal as part of their process to capture and store structural information in the registry. This effort will involve developing tools and products, including an Elevation Certificate How-To Guide for EC generation, to attract and maintain usage of the system by such users. We would prefer that surveyors not have a way to by-pass posting the structural information to the registry. Remote sensing data collected after the implementation of the elevation registry will be quality reviewed for accuracy (in accordance with one of the Options listed below) and certified according to FEMA standards. After certification, data will be posted to the registry by FEMA or a FEMA cooperating technical partner (CTP) or contractor using a back-end portal. During the design of the elevation registry, it is anticipated that schedules will be determined for adding and/or updating records through the back-end portal from existing data sources, including NEMIS and BureauNet. As noted above, the system administrator who controls the database will resolve any conflicts between existing and new records and ensure that the registry is not corrupted. CRS communities annually submit ECs to ISO as part of their CRS requirements. Until such time as all surveyors who prepare ECs are using the front-end portal, these ECs will be compiled and processed for loading into the elevation registry through the back-end portal. As in Phase I, ECs submitted by communities may include those ECs already in a database format as well as ones that need to be scanned and digitized and those that need to be digitized from existing scans. Elevation Registry System Requirements This section will address three options for flow of data between users and the registry: (1) centralized processing, (2) distributed processing, and (3) web portals. A key distinction among users is the quantity of structures the user will provide or request per transaction. Surveyor and insurer eRating transactions will primarily consist of single structure information, while remote sensing data providers (i.e., contractors and communities) will primarily engage in multi-unit Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY transactions. Transactions involving LOMAs can involve both single and multiunit transactions and will have to be considered separately. To develop the system interface, data providers are categorized into three major categories: • Single-structure data users (requestors or providers). An example of a single- structure data requestor would be an insurance agent authorized to read and print individual records and be charged a transaction fee from a draw-down account, or perhaps a real estate agent or potential home owner seeking information on a structure of interest, for which charge cards could be used for billing purposes. An example of a single-structure data provider would be a surveyor authorized to enter individual EC records based on their surveyor's license and seal. Single-structure data users would interact directly with the front-end or back-end web portals (Option 3 in Figure 14 below), but the site would need to authenticate the surveyor's credentials before accepting new EC data into the registry. To minimize costs, Dewberry recommends that Option 3 be operated as an add-on to FEMA's current Map Service Center (MSC) web site for reasons explained previously. FEMA also operates other centralized web portals for NEMIS and LOMA 2000. • Multiple-structure data users (requestors or providers). An example of a multiple-structure data requestor would be a community NFIP or CRS coordinator who needs to review all records for his/her community. An example of a multiple-structure data provider would be a community that is submitting batch files of digitized ECs or batch files of remote sensing data from Methods 8, 14 or 17. Depending on whether or not the user is a CTP, either Option 1 or Option 2 of Figure S.3 could pertain. For example, a CTP would agree to maintain certain levels of expertise so that the partner's specialist (normally NFIP or CRS coordinator) could perform specified transactions for input and output of data covered by the CTP agreement; then, Option 2 could be exercised with a Distributed Processing Center, and there would be no fees charged for output of data or reports. If the user is not a CTP, then data requestors and providers would both interact with a Centralized Processing Center, Option 1, operated either by FEMA's National Service Provider (NSP) or a different FEMA contractor, and fees could be charged for services provided. Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY Data Requestor / Provider Web Access Available or Allowed? Authenticate User Yes No Multi- Structure Da ta Provider? CTP available? Yes Log Transaction Log Transaction No Yes Authenticate User Authenticate User Process Transaction Generate Reports Publish/Post Data Respond to Requestor / Provider Option 1 - Centralized Processing Center Option 2 - Distributed Processing Center Option 3 - Web Portals (Front- & Back-End) No Figure S.3 — User Logic Process for Three Options. • Special-case data users (requestors or providers). An example of a special- case data requestor might be a FEMA Analyst searching for repetitive loss properties in a community. An example of a special-case data provider might be a LOMA Analyst entering data into the LOMA 2000 database, linked to the registry, for input of individual LOMA records or perhaps the LOMA record for an entire subdivision (one LOMA covering multiple addresses). Such users would have access to any of the three Options. With Option 1 (Centralized Processing Center), the import or export of large datasets will be managed and quality controlled in a centralized location. Its primary function will be to process and quality control incoming data, reformat data into a standardized format, and batch enter large datasets from Strategy A or B. The advantages are: (1) easier enforcement of standards, (2) easier training of the staff involved in the process, and (3) easier and quicker procedures for upgrades and changes. The disadvantage is higher costs to FEMA compared to Option 2 where CTPs bear major costs. With Option 2 (Distributed Processing Centers), the import or export of community data will be managed and quality controlled by states, counties or communities who choose to manage their own data and sign a CTP agreement to do so. The advantage is lower cost to FEMA compared with Option 1, but the disadvantages are: (1) harder enforcement of standards, (2) harder training of the staff involved, and (3) more difficult to upgrade and change procedures. Some communities already operate their own web site for provision of ECs to the public, and FEMA should encourage such practice by others. Option 2 is a half- step in helping communities meet this goal. With Option 3 (Centralized Web Portal), the import or export of data for individual structures is direct with the web portal. Individual users interact directly with the front-end portal designed to be user friendly. The Web portal will register and authenticate users automatically as well as allow data queries. Beyond the cost Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY of developing the web site, FEMA would not bear any major additional costs associated with data entry and requests through this system, except when protocols need to be revised and updated. This option is the major way that FEMA receives cost reimbursement from data requestors who use the registry for real estate queries or eRating, for example. General Assumptions • No data providers will be allowed to submit data directly to the elevation registry because this may unintentionally corrupt the data base. All data will pass security checks before being posted. • Land surveyors and remote sensing contractors are registered with and/or licensed by a state Board of Registration for Professional Engineers and Land Surveyors which protects the public from harm that could be caused by unlicensed surveyors. Remote sensing firms are similarly licensed, based on ownership or management controls by licensed professionals. Because licenses can be revoked or suspended because of non-professional performance or negligence, professional registrations helps to ensure the accuracy of data input from surveyors and remote sensing firms. • Alternative options all have essentially the same short-term costs for setting up the web portal. • Cost of data collected through the LOMA process and NEMIS will not be incurred by the elevation registry. General Criteria • Minimize maintenance costs. • Use other FEMA programs to maintain the data and absorb costs (e.g., Map Service Center, CTP and CRS). • Adopt flexible strategies that are adaptive to technological changes and minimize interoperability issues. • Provide added value to users by saving time through automation or elimination of specific tasks and report generation. Authentication of Data Providers. For legal and programmatic reasons, methods to authenticate data providers will be required before data can be posted to the registry. Authentication will be required when the data provider first registers with the system and a profile is generated. Depending on the available of resources, authentication may be required periodically to validate user information. Given that one solution will not be suitable for all data providers and circumstances, three alternatives will be considered: • On-line authentication • The data provider submits documentation directly to the elevation registry processing center, either with the National Service Provider or other FEMA representative or contractor. • The state licensing Board submits an annual validation form to the elevation registry processing center listing all Land Surveyors and license numbers. Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY Data Certification. Since data posted to the system will be generated from multiple sources using different techniques, not all data in the registry will have the same level of accuracy. Furthermore, some users, such as insurance providers, will require less accurate elevation information than others. As a result, to address legal and scientific concerns, the registry will capture additional information about elevation data, such as: • Level of accuracy (dependent on quality control and collection methodology) • Certified by a licensed Land Surveyor or uncertified • Methodology (e.g., aerial survey; ground survey, GPS or conventional; NGS benchmark used as the basis for elevation surveys) E-signatures. When legal and feasible, users can submit data and generate legal documents (e.g., Elevation Certificates) using e-signatures. Otherwise, data providers will have to submit data and documentation using conventional methods through a processing center. Input and Output Protocols. eXtensible Markup Language (XML) and Geographic Markup Language (GML) formats are recommended to eliminate interoperability issues. XML and GMS (a subset of XML) are types of metalanguages that serve to define other languages and their data. With XML, one can define the structure of data used, have data be platform-independent, automatically process data defined by XML, and define unique markup tags that hold FEMA's data elements. The simple and consistent nature of XML makes it very useful for exchanging data between many types of applications. GML was developed to describe spatial data and spatial data properties and is used by WMS and WFS. WMS and WFS are Open GIS specifications that facilitate the interoperability of web-based applications and data, principally for portal technologies. User Output Reports: • Capture additional information to benefit users such as surveyors • Generate hardcopy ECs automatically • Generate summary reports for users, e.g., all ECs generated by a specified surveyor • Generate a report, containing a map, for the user clients. A FIRMette is already an option available from the MSC. • Provide EC data for use in GIS applications through WMS and WFS. FEMA Reports: • Generate exception reports • Flag structures or users that do not satisfy specific criteria, e.g., lowest floor elevations, or lowest elevation of machinery (LEM), if below the BFE; in the case of LEMs, air conditioner pads could be elevated, or equipment could otherwise be protected from water damage. • Flag new elevation data that is significantly different from prior data on the same structure. Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry APPENDIX S — WEB-BASED REGISTRY • Identify data providers that consistently provide questionable elevation data for structures. • Mitigation analyses. Identify repetitive loss structures or structures that might otherwise be candidates for retrofitting or buy-out. • Verify flood policies or whatever else BureauNet is used for. Overall Strategy The primary data collection and delivery mechanism will be the central Web portal already operated by the MSC. The centralized user interfaces constitute the most cost effective strategies for the following reasons: • Minimal setup and distribution costs • Low maintenance and upgrade costs • Universal access • Existing security functionalities • Existing E-commerce procedures for user authentications and payments Evaluation of Alternatives in Obtaining Structural Elevation Data Dewberry