FHWA Integration of State, Tribal, and Local Safety Data

FHWA Integration of State, Tribal, and Local Safety Data
Guide and Data Business Planning Technical Assistance Traffic Records Forum August 2017

Introductions The FHWA representative and VHB facilitator will lead a round of general introductions, beginning with FHWA who will introduce themselves, their role, FHWA’s role in the project, and a brief welcome. Next the VHB facilitator will introduce themselves, their role, and a brief welcome. Facilitator should also provide instructions meeting materials and meeting logistics, including any people on the phone, meeting format, ground rules, and restrooms/refreshments The VHB facilitator will then lead a round of introductions of all participating agencies in the room. Participants will state their name, their agency, and their interest/goal in participating in the meeting.

Purpose and Goal Understand the data integration process
Understand its development & implementation Know its benefits Fit into Data Governance & Data Business Planning Develop a roadmap for data integration

Data Integration Link multiple data sources to meet users’ needs
Integration can take place: Across jurisdictions Among safety databases Safety Data = Crash, Roadway, and Traffic

All-Public Road Network of Linear Referenced Data
ARNOLD Requirement for geospatial network State responsible for: All Public Non Federal Owned Highways

Strategic Highway Safety Plan
SHSP needs to have a data emphasis area Qualify for HSIP funding

Subset of MIRE to be Collected
The FHWA developed the MIRE, a recommended listing of roadway and traffic elements critical to safety management. MAP-21 required the Secretary to establish a subset of the MIRE – Adjusted in FAST Act The FDEs are categorized by roadway functional classification and surface type and include three tables, one each for non-local paved roads, local paved roads, and unpaved roads Further refined into subcategories of data elements for road segments, intersections and interchanges MIRE FDE – minimum elements for safety analysis MIRE FDE varies based on functional classification, surface type, and subcategories of data elements (segments, intersection, and interchanges) Subcategories for segments, intersections, and interchanges

Collecting and Using the MIRE FDEs
States shall incorporate specific quantifiable and measurable anticipated improvements for collection of MIRE FDEs into their State Traffic Records Strategic Plan update by July 1, 2017. States shall have access to the FDEs on all public roads by September 30, 2026. Plan for data improvements by July 1, 2017 – Traffic Records Strategic Plan Access to all FDE by September 20, 2026

Collecting and Using the MIRE FDEs
States should develop strategies that consider: The current status of MIRE FDE collection efforts Appropriate data collection methodology Coordination with other agencies Prioritization criteria for collecting MIRE FDE The schedule and estimated costs for data collection efforts Planning effort should be specific, measurable, achievable, realistic and time-bound strategies for the collection, maintenance, and management of MIRE FDE Planning should be: specific, measurable, achievable, realistic and time bound Identify gaps, Develop methodology Coordinate with other agencies Prioritize Collection Schedule and cost for collection

Prioritization Base layer Crash Location MIRE FDE
Conducted research using: Reached out to FHWA Division Offices. RSDPCA data available through FHWA Results from FHWA’s Assessment of GIS Needs and Obstacles in Traffic Safety Project Results from NCHRP Synthesis 44-05: Roadway Safety Data Interoperability between Local and State Agencies Follow-up contact with nine States

Background State Safety Data System Safety Data MIRE FDE
All Public Roads Common Base Map Crash Data System Roadway Data System Analysis and Evaluation Highway Safety Improvement Program Traffic Data System

Benefits of Safety Data Integration
FAST-Act requires all States have a safety data system to perform problem identification and countermeasure analysis on all public roads; adopt strategic and performance-based goals; advance data collection, analysis and integration capabilities; determine priorities for the correction of identified safety problem; and, establish evaluation procedures. The FHWA data driven safety analysis allows for: Better data for: network screening, prioritization, countermeasure selection, and evaluation improves analysis outcomes Better/more informed decisions, more efficient use of funds, improved safety “Data integration supports decision-making in ways that the individual data systems cannot. This brings us back to the opening discussion of integration across jurisdictions and among the core safety data sources. When target agencies bring together their safety data, the resulting integrated resource supports scientifically valid, rigorous, and complete analyses. The information developed from those analyses helps decision makers better understand the human, vehicle, and environmental factors that contribute to safety. As illustrated in the figure, improved data means that decision-making can address all public roads, resources are allocated where they will have the largest safety impact, lives are saved, and injuries are avoided.”

Benefits of Safety Data Integration
Availability Timeliness Accuracy and Integrity Consistency and Clarity Completeness Reduce Duplication

Benefits of Safety Data Integration (continued)
Faster Processing Time Lower Data Acquisition and Storage Cost Informed and Defensible Decisions Enhanced Program Development Greater Accountability

Current Challenges Lack of formal processes
Partnerships across agencies Move to all public roads network

Data Business Planning
A formal planning process Describes data needs and how to fill them Includes a roadmap to completion Action / implementation plan Inclusive and cooperative

Data Management & Governance
Data Management: Top-down decisions on IT environment, methods, and tools. Data Governance: Implements those decisions in specific domains or enterprise-wide. Stakeholders: The people who collect, store, extract, translate, load, and use the data.

Integration of State and Local Data
Built on the results of the RSDPCA Research, case studies, and pilot studies Resulted in guidance to assist agencies Roadway Safety Data Program Capabilities Assessment

Case Studies Identified States & agencies for case studies
Identified potential candidates for pilot project Researched noteworthy practices by States Conducted research using: Reached out to FHWA Division Offices. RSDPCA data available through FHWA Results from FHWA’s Assessment of GIS Needs and Obstacles in Traffic Safety Project Results from NCHRP Synthesis 44-05: Roadway Safety Data Interoperability between Local and State Agencies Follow-up contact with nine States

Case Studies Purpose: Understand data integration solutions that meet the combined needs for asset management and safety data. Provide descriptions of methods that States have used in successfully collecting, integrating, and updating local safety data. Identified potential candidates in Task 2. Candidates chosen by Advisory Panel Weightings and FHWA final decisions.

Case Studies Michigan’s Roadsoft Ohio’s Location Based Response System
Tennessee Roadway Information Management System Wisconsin Information System for Local Roadways

Case Study Findings Less duplication of data collection efforts
Many paths to safety data integration States do best if they pay for the effort Local input is required Executive-level support is key Less duplication of data collection efforts Many paths to safety data integration: Who leads? (State, Locals, Tribes, others?) Which data files are integrated? States do best if they pay for the effort Local input is required Executive-level support is also key

Work Plans and Pilot Studies
Fort Belknap Reservation/ Northern Plains TTAP Purpose: Provide agencies with expert assistance in support of implementing data integration Included: collection, data quality, integration, analysis, treatment selection, management, promotion, marketing Identified potential candidates in Task 2. Used information from Tasks 3 and 4 to refine.

Purpose of Work Plans Develop a plan for implementation
Provide examples on how to structure a safety data integration project A total of 6 work plans developed, of which 4 went on to full pilot studies

Pilot Study & Work Plan Outcomes
Informational guide Strategic plan Nine-step data integration process Pilot Study lessons informed the development of the informational guide and strategic plan. The experience with a variety of agencies was distilled into a nine-step data integration process.

Informational Guide for State, Tribal, and Local Safety Data Integration
FHWA SA

Purpose of the Guide Make data integration approachable!
Provide easy-to-use information to support data integration efforts Show examples from other States and agencies Identify potential partner agency needs Direct users to web resources Make data integration approachable!

Safety Data Integration

Safety Data Integration Steps

Technical Assistance Overview

Purpose of Technical Assistance
Assist States in developing Steps 1–5 of data integration plan Provide States with guidance on how to complete Steps 6–9

Needs and Barriers Typical Needs Integration of local data
Improved data quality on local roads Improved asset management procedures Data governance process Analytic tool selection & training Data business plan: collect, store, and use Upper management buy in

Needs and Barriers Barriers Inter-office responsibilities
Staffing, capabilities, and availability of tools at local agencies Institutional inertia

Safety Data Integration: Steps 1 – 5

Step 1: Lay the Foundation
Learning Objective: Review Step 1 of the process Discuss what steps the State has done to date to meet Step 1 Discuss what the State can do in the future to meet Step 1

Objective Bring together people responsible for managing safety related data and their consumers ALL PUBLIC ROADS LRS Crash Records Roadway Inventory Traffic Volumes Identify Safety Data Users Establish roles and responsibilities

Potential Partners State and Tribal Personnel Local Personnel Others
Executive staff in DOT and information technology (IT) roles Safety engineers Safety program managers Geographic Information System (GIS) managers and staff Enterprise data stewards Roadway inventory data stewards Crash data stewards Traffic volume data stewards Planners Design engineers/managers Maintenance engineers/managers Asset managers State law enforcement agencies LTAPs/TTAPs Executive leaders GIS managers IT staff Public works managers MPO and RPC staff Designers/planners Traffic engineers Maintenance engineers E911 managers County appraisers/auditors Local law enforcement agencies FHWA division offices FHWA headquarters staff NHTSA and FMCSA regional offices NHTSA and FMCSA headquarters staff US Parks Service Bureau of Land Management Bureau of Indian Affairs Engineering consultants Safety advocates Safety educators News media General public Questions: Which of these are represented in the room today? Who is a partner but not represented in the room today? Who are the potential partners to engage? What is needed to establish those partnerships?

Challenges Data silos Proprietary interests of data owners or users
Support from all levels of management Communication with all stakeholders Partners’ business needs & reporting requirements vary

Step 1 Summary Secure the commitment of executive management
Forge partnerships Establish needed MOUs and Data Sharing Agreements to establish expectations Establish communication processes to inform and involve all stakeholders

Step 2: Conduct Gap Analysis

Objective Document business needs and reporting requirements
Identify existing and future safety analysis tools Generate list of supporting data requirements Identify common data between departments Compare available data sources Identify needed improvements A gap analysis compares the current conditions to the desired conditions, and points to needed improvements. For safety data integration, a gap analysis is a formal investigation comparing the available data sources to what is needed. Needs are defined by required data to support the intended type of safety analyses and the desired safety analytic tools.

Challenges Funding and development schedule trade-offs
Partnerships among agencies Data gaps analysis shouldn’t be stand-alone System life-cycle management & sustainability Challenges identified in the case studies (Michigan, Ohio, Tennessee, and Wisconsin)

Data Gaps Analysis as Part of Data Governance Process
Integration steps 1-3 form a three-part cycle as an agency matures Partnerships need to evolve as users’ needs change Updated gap analysis can help with business planning and promote discussion Data Governance Lay the Foundation Conduct Gap Analysis

Step 2 Summary Establish a team to perform the gap analysis
Perform a survey of user needs and available data sources Plan to repeat the gap analysis periodically Recognize the interactions between forging partnerships, gap analysis, and data governance efforts Lessons Learned: Include a data gaps analysis in all integration projects Data gaps are one part of larger issue Step 2 is important in Steps 1, 3, 4, 5

Step 3: Establish Data Governance Process

Objective Formal process Address data systems and management issues
Data definitions Data standards Lines of authority and ownership Access rights and usage Data lifecycles Requires input from key stakeholders

FHWA Data Governance Plan
Six Strategic Goals Leadership Quality Prioritization Cooperation Flexibility Utilization Leadership: Identify champions to ensure accountability and to increase the value of data assets. Quality: Establish procedures to ensure data are sufficient for the intended users. Prioritization: Prioritize efforts to address data gaps and needs. Cooperation: Facilitate cross-organizational collaboration, data, sharing, and integration. Flexibility: Encourage creative and innovative solutions to data needs. Utilization: Improve data utilization and ease of access.

Management (top level decisions) Governance (implementation) Stewardship (the people) Stewardship Governance Management

Leadership: Identify champions to ensure accountability and to increase the value of data assets. Quality: Establish procedures to ensure data are sufficient for the intended users. Prioritization: Prioritize efforts to address data gaps and needs. Cooperation: Facilitate cross-organizational collaboration, data, sharing, and integration. Flexibility: Encourage creative and innovative solutions to data needs. Utilization: Improve data utilization and ease of access.

Data Governance Challenges
Data sharing may be new experience for some agencies Control over data may be compromised Roadways constantly change All-Public-Roads expands data requirements Queries are complex using distributed data Some agencies may be concerned over exposure to risk of tort liability, legislative backlash, or difficult public interactions. The data integration efforts will link files with sensitive personal information.

Step 3 Summary Identify leadership and establish a data governance committee Establish a data quality assurance program Establish clear priorities to address data gaps and needs Identify opportunities for cross organizational collaboration and data sharing & integration Communicate with stakeholders Utilization: Promote appropriate data usage Lessons Learned: Inclusive data governance group Emphasis on data quality performance measurements Leadership. Committee monitors data integration Quality. Should include data standards and measures of data quality Prioritization. Cooperation. Establish an MOU Flexibility: Share innovative solutions with stakeholders and partners Utilization.

Step 4: Develop Data Collection and Integration Plan

Objective Describe actions required to move to desired outcome
Outlines necessary steps Identifies responsible partners Ongoing status updates Addresses needs identified in Step 2 This is very closely related to the Traffic Records Coordinating Committee traffic records improvement plan. Both address safety, are developed by a coordinating committee, and should be inclusive of all projects that will impact safety.

Data Plan Challenges Challenge
Anticipate some resistance in initial stages Agencies vary in capabilities, technology, and data Multiple data formats & platforms complicate integration Use existing TRCC and possible existing data governance group as models for structure and function. Data sharing agreements and MOUs may help to formalize the group and formally ask it to deliver a plan that the partner agencies can endorse and adopt

Step 4 Summary Start the data integration plan in conjunction with gap analysis and data governance efforts Identify integrator, provider, and maintainer roles Develop a plan as an implementation plan Lessons Learned Start as early as possible Pick the easiest integrations first Define and understand task dependencies Consider taking an existing established group with the plan’s development Include full lists of actions within tasks and explicit recognition of task depedencies

Step 5: Identify Training Needs for Data Collection, Integration, and Analysis

Objective Formal, comprehensive process
Compare staff knowledge & skills to identified needs Draws on previous and subsequent steps Identify the skills needed for tasks and relevant stakeholders Skills for data integration include: Data b

Data Integration Required Skills
Database management Data quality measurement and management Merging datasets based on common variables Location-based, spatial data management, display Data standards knowledge System documentation Safety data analysis tools and methods HSM safety management process What organizations, present or not, may have the staff with such capabilities? What skills can your department/organization address? What skills or areas do you need to seek out additional partners to cover?

Training Challenges Challenge
Identifying most appropriate and cost-effective training Training needs exceed time & resources Existing training may not meet all needs Cross-training and backup/understudy training needs exceed time & resources

Step 5 Summary Assess stakeholder needs related to data integration training and TA opportunities Develop formal process to address data integration training and TA requests Discuss local agency needs with other agencies to identify training and TA opportunities Identify needed resources to address TA requests Lessons Learned: Training needs assessment may be a continuous process Both training and technical assistance are needed Resources may include staff time, funding, and additional partnerships

Safety Data Integration: Steps 6 – 9

Implementation Steps Steps 6 – 9 focus on plan implementation
Purpose of TA is to provide States with the recommendations to complete the steps

Step 6: Perform Data Integration

Objective Merge two or more data sources into one resource
Purpose: Improve safety through improved analysis End result: A database supports that supports the intended safety data analyses Two safety data approaches: Combine multiple spatial data source files into one centralized GIS or other file type Treat spatial data as linking variable in standard database merge operation

Data Integration Challenges
Data insufficiency Heterogeneous data Bad data Unanticipated costs

Step 6 Summary Follow the data integration plan and understand it will be iterative Maintain cooperation among stakeholders Use software tools to enhance data routines Anticipate future data and storage needs Monitor and manage the data integration plan Lessons Learned It is possible to successfully integrate poor quality data Plan for an iterative process The lead agency always needs help from people

Step 7: Develop and Deploy the Extract, Transform, and Load Process

Objective Process where integrated safety data are made available for analysis Formal, documented sequence: E: Extract data out of native system T: Transform into required format L: Load into analytic software

Data Extraction Create an analyzable subset of the total dataset
Pull only records of interest from a database May not result in a complete desired data set Example: take one year’s data from a multi-year dataset or take the data for one roadway type out of a file of all data for all roadway types Data extraction tools range from software to spreadsheets and include the following common features: Filter Cases, aka Select Cases Data Extract, aka Subsetting Exclude Cases Join and Filter Spatial Filtering

Data Transformation Change data to match the requirements of the analysis tool’s data import process Depends on selected software and based on specifications for data import files May imply specific layout, file type, or database type Example – recording variables, converting from the native database to a spreadsheet or flat file, restructuring the data file The process is highly repeatable and should only fail if the data contain serious errors or data type mismatches that generate unrecoverable errors

Data Load Typically manually controlled
Involves software tool user specifying: A data file Specified location Selecting the software controls to import data Some tools run a data quality part of the load process, while others produce error reports only if the use of the data fails

GIS-Based Data Integration
Digital representation of real world Map locations to a sufficient level of accuracy LRS locations need to map correctly to the GIS representation of the roadway network May use dynamic segmentation

Spatial Data Analysis, Filters, and Extraction
Spatial buffers can be used to compare data in one layer versus another Spatial analysis uses GIS and other tools to assess spatial relationships among various data elements and features

ETL Challenges Challenge User feedback Access to metadata

Step 7 Summary Extract: Transform: Load: User Feedback:
Program software tool to transform data to meet the needs of the analytic software Load: Load the translated data into the analytic software tool User Feedback: Develop utility to collect feedback from users Ensure that relevant metadata are provided to users Filter or select cases Join and filter Create data extract Filter spatially Exclude cases Lessons Learned ETL processes are a good source of data quality information Spatial and non-spatial data extraction are similar

Step 8: Conduct Analyses
Learning Objective: Review Step 8 of the process Discuss what steps the State has done to date to meet Step 8 Discuss what the State can do in the future to meet Step 8 Proposed time 15 minutes

Objective Conduct safety analyses with newly integrated data
Ultimate goal is to determine the most effective approach to improve safety, save lives, reduce the number of severe injuries Key is to select most appropriate analysis Safety analyses may include traditional safety analyses, advanced analyses (such as the HSM), novel analyses that an agency may create for their own purposes, and analyses aimed at making safety information available for decision-making in other areas beyond the core safety management area There is no ‘one size fits all’ approach to selecting analysis methods

Types of Safety Analyses

HSM methods Predictive Systemic Data visualization
Safety can be measured with performance measures. One or more performance measures can be used – using multiple performance measures may improve the level of confidence in the results. Performance measures: Crash rate Average crash frequency Excess predicted average crash frequency using Safety Performance Functions (SPFs) Probability of specific crash types exceeding threshold proportion Excess proportion of specific crash types Level of service of safety Excess Predicted average crash frequency using method of moments Critical rate Equivalent Property Damage Only (EPDO) Average Crash Frequency Relative severity index Excess expected average crash frequency with EB adjustment Expected average crash frequency with EB adjustments EPDO average crash frequency with EB adjustment

Types of Safety Analyses
Network Screening: Analyzing the entire network to identify potential sites or issues for further investigation Site-specific: identify specific sites for further analysis (typically those with high crashes or over-represented crashes). Systemic: identify common risk factors of crashes (typically those that are most prevalent across the network).

Systemic Network Screening
State/Local Data Integration Opportunities for Enhanced Analysis Systemic Network Screening March 5, 2015 Why systemic? Fatalities are a moving target

Data Visualization

Performance Metrics Key considerations for selecting performance measures: Data availability Typical data Regression-to-the-mean bias Crashes naturally fluctuate over time Selection bias How the performance measure threshold is established Provides reference point Subjective or objective Key considerations for selecting performance measures include: Data availability – typical data includes the facility information for establishing reference populations, crash data, traffic volume data, and, in some cases, safety performance functions. The amount of data and inputs available limits the number of performance measures that can be used. Regression-to-the-mean bias – crash frequencies naturally fluctuate over time and as a result, a short-term average crash frequency may vary significantly from the long-term average crash frequency. When a period with a comparatively high crash frequency is observed, it is statistically probably that a lower crash frequency will be observed in the following period and vice versa. With a three-year period, it would be difficult to know if the period represents a high, average, or low crash frequency at the site compared to previous years. If this three-year period was used as the basis for treatment selection, it would be known as “selection bias” due to the failure to account for RTM. How the performance measure threshold is established – provides a reference point for comparison of performance measure scores within a reference population. Those sites with a performance measure score less than the threshold value can be studied in further detail to determine if reduction in crash frequency or severity is possible. The method for selecting a threshold is dependent on the performance measure selected and can be subjectively assumed or calculated as part of the performance measure methodology. Typically, the methods that require more data and address RTM bias produce more reliable performance threshold values.

Challenges Limited empirical data Limited funding Training limitations
Data input and the diversity and inconsistency of data Lack of understanding of the limitations of analytical tools Lack of features Tendency to use simpler analytical tools Long run times FHWA’s Traffic Analysis Tools Data Integration Primer identifies several challenges and limitations associated with adopting a roadway and safety analysis tool: Limited empirical data: Data may still be lacking for certain types of analyses, but data collection can be a very costly component of a study. The best approach is to focus data collection based on the look at the ultimate goals and objectives of the analysis. Limited funding: Conducting the study, purchasing tools, running analytical scenarios, and training users are all typical costs that should be considered. Analysis tools and software and training are all additional costs that may add to the constraints of funding. It is important to identify the point of diminishing return for the investment to keep costs under control. Training limitations: Some users may not receive adequate training or have to time to learn a new program, many of which have steep learning curves. Data input and the diversity and inconsistency of data: Data requirements for analysis may differ from tool to tool due to the varying types of analytical methodologies. Lack of understanding of the limitations of analytical tools: Limitations are often uncovered once a project is underway. Lessons learned from previous projects should be communicated in order to assess the tool’s capabilities and limitations. Lack of features: Some analytical tools are not designed to evaluate the specific strategies and countermeasures the users would like to implement. Flexible tools allow advanced users to customize the tools. Tendency to use simpler analytical tools: Agencies may turn to tools currently in their possession, despite the best fit for their project. This may be a result of limiting factors such as resources, past experiences, or lack of other available tools. Long run times: Analytical models may run anywhere from a few seconds to a few hours.

Step 8 Summary Review the Primer on Safety Data and Analysis Toolbox and the Scale and Scope of the HSM Conduct analyses and produce analytic reports. Support users. Lessons Learned Analytic users may be found at all agency types Agencies need help deciding which tools to test and adopt Changing analytic tools changes what has to be accomplished in many of the other steps in the integration process

Step 9: Perform Effectiveness Evaluation
Learning Objective: Review Step 9 of the process Discuss what steps the State has done to date to meet Step 9 Discuss what the State can do in the future to meet Step 9 Estimated time 15 minutes

Objective Evaluate the effectiveness of data integration, not individual projects Identify which activities resulted in reducing crash frequency and severity Make connections between integrated files and improved safety decisions

Challenges Lack of multi-year projects utilizing integrated data over a period of time Quantitative analysis is not yet available… … Yet links can be made between better data, better decisions, and improved safety This will be a long term process, becoming more feasible to quantify the links over time. Results will analysis will help to justify the costs of more extensive data integration.

Step 9 Summary Increase the use of predictive methods as data integration processes mature Increase the number of agencies included in data sharing agreements and data governance processes Lessons Learned: Need more years of data and advanced analyses. Noteworthy practice recommendations are potentially a way to measure the success of data integration.

Data Business Planning

Implementation Roadmap

Closing Discussion

Contact Information Stuart Thompson, FHWA Bob Scopatz, VHB

FHWA Integration of State, Tribal, and Local Safety Data

Similar presentations

Presentation on theme: "FHWA Integration of State, Tribal, and Local Safety Data"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

FHWA Integration of State, Tribal, and Local Safety Data

Similar presentations

Presentation on theme: "FHWA Integration of State, Tribal, and Local Safety Data"— Presentation transcript:

Similar presentations

About project

Feedback