Intro

Informal Opening Discussion

Crash DB Systems Review

TraCS Systems and Crash Form development

Dave Malisch / Geri Polster

TOPS Database and WisTransPortal

Steven Parker / Andi Bill

Maintenance Updates and System Stability

• Upcoming Maintenance Windows:

  • July 28 – Monthly server maintenance window.

  • July 31 – Low Risk Resolve Update (JIRA Cases)

• Prioritized JIRA Issues and Enhancements

  • JIRA In Progress

    • https://wi-state-patrol.atlassian.net/browse/CRASHDB-989

      • User acceptance version on UAT server environment

    • https://wi-state-patrol.atlassian.net/browse/CRASHDB-1610

      • User acceptance version on UAT server environment

    • https://wi-state-patrol.atlassian.net/browse/CRASHDB-1637

      • General system issue – continuing to investigate

  • JIRA On Deck:

    • https://wi-state-patrol.atlassian.net/browse/CRASHDB-1626

    • https://wi-state-patrol.atlassian.net/browse/CRASHDB-1627

    • https://wi-state-patrol.atlassian.net/browse/CRASHDB-1570

      • TST is complete, next step UAT environment

• Purge and Archiving Processes

  • Purge and Archive processes continuing to run smoothly.

  • 1,128,460 total archived crashes of which 520,813 represent purged crashes (the archive adds approximately 13K crashes per month).  This includes 2,112,343 total image files.

• HWYCLASS Working Group

  • Working group meeting Tuesday, July 2

    • Focus on functional class for 2023 HSIP

    • Evaluation of 2022 KA crashes using RP crash values

    • https://wi-state-patrol.atlassian.net/browse/CRASHDB-1576

• WisTransPortal / Community Maps

  • Community Maps County Profiles Updated

  • First Community Maps “Virtual” Office Hours July 8 (second Monday)

  • Working with BTO (AASHTOWare), City of Madison (Citian)

Crash Records Unit

Polly Ebbinger / Mike Satteson

Issue Resolution Summary

CrowdStrike Impacts

There were no data losses that we are aware of. 4 CRU team members, two RP coders and both lost the use of their machines. All 4 machines were recovered. @Michael Satteson's workstation was affected and was unavailable until Monday afternoon. The impacts of losing this machine were temporary losses of

• SAS capabilities,

• The most recent FARS Access DB

• A Julia environment curated to maintain compatibility data snapshots going back to 2017

Without SAS the CRU was unable to run the usual daily and weekly updates of crash data libraries. Several years ago the Department considered switching from client to server based SAS, but declined to do so. The reason was not the cost of the move but the thought that the use of SAS would be sunsetting in the department, making the server solution less economical over time. Server SAS would our current single point of failure in the crash DB to SAS library chain.

The old Access DB breaks when it is not run locally. I do make backups to box, but was 1 day stale when cloudstruck. That would have been recoverable but turned out not to be needed as we got the most current file back in time for Monday’s daily and weekly fatality report. All other FARS case management activities proceeded as normal.

While waiting for repair of my workstation, I converted the old crash data files to be compatible with a fully up to date Julia toolchain.

FARS Systems Status

Cases Without Crash Reports

• Under Review

• Awaiting Screening

The CRU has been in frequent contact with the Milwaukee PD records department regarding fatal crashes without a DT4000 crash report. @Polly Ebbinger recently provided Milwaukee county’s LEL Randy Wiessinger with a detailed fatal crashes for that county missing DT4000s and fatal supplements. Three crashes without DT4000 reports is a is modest by recent standards, but is is concerning that over a month has passed for these three with two going on two months old.

FARS Screening and Cause of Death Verification

In the old days, the evaluation of fatalities and crashes was informal and intuitive. The process worked because after decades of experience Scott Stary could look at crash information and make a snap decision as to whether the crash was FARS reportable.

We’ve replaced that process (which was highly dependent upon a single skilled worker) with a more systematic and formal screening and verification of both the crash and injury circumstances relevant to crash reportability. The crash factor screening and verification is less frequently a concern and generally take less calendar time to complete than does that of the injury circumstances. So let’s consider the injury aspects.

Injury screening consists of looking for indications that a fatality was not the result of crash injuries or that the death was intentional (i.e. suicide or murder). Often the narrative will indicate that the investigating officer suspects that the person did not die because of the crash. There are also some general scenarios that point of Non-Motor Vehicle Traffic Fatality (NMVTF). For example a run off the road crash with a little or no vehicle damage but a dead driver may be an instance of the driver having perished prior to the crash, which would be a NMVTF and not FARS reportable.

Whether a fatality is judged to be FARS or NMVTF we follow-up with verifications, which depends upon obtaining death certificate information of the individuals. As with the screening, we are moving to a more systematic verification of the cause of death. Thanks to automation this work is quick and easy for the majority of fatalities for which we get death data in monthly extracts.

We could do even better if we could obtain more comprehensive death certificate data in the extracts that we receive from DHS vital records.

DMV Systems and SR

Ken Matthews

Reference Point Coding

Ben Rouleau / Asadur Rahman

Crash Data Analysis and Reporting

Valerie Payne

Scheduled Topics and Briefing documents

Close

Informal Closing Discussion