Changes to state crash report form

Issue

States periodically update their crash report form. This article describes how those changes will affect your use of that data in Crash Magic Online.

Explanation

New crash report forms may be similar but in some critical ways different from the form in use today.  Specifically, fields may have been added, fields removed, but most importantly: The values in the fields may have changed!  Unfortunately, rather than adding the new values to the end of the list, new values may have been inserted into the middle of the list.  So a table that used to look like this:

  1. Blue
  2. Green
  3. Red
  4. Silver

may now look like this:

  1. Blue
  2. Yellow
  3. Green
  4. Gold
  5. Red
  6. Silver

This means that when a yellow car is involved in a crash, the officer will now code it as a “2”.  That “2” will likely be written to the file that Crash Magic imports.  Crash Magic will see that “2” and interpret it as a green car. 

As you can see, changes like this can be substantial and will affect any application that uses data from these forms.  As a result, you should not import this new data into your existing database until your importer and/or complete configuration are updated.  It will result in incorrect data in the program. 

Solution

Your data providers 

The most important information you will need in order to handle this situation is: how is the holder of your data dealing with this change?  This may be your police department, the state, the county, etc.  It may even be a 3rd party that provides data entry software or services to your agency.  You may also be entering the data yourself using Crash Magic Data Entry.

Your data provider will probably do one of three things (in order of our opinion of preferred strategies):

  1. Convert all old data to the new values:  In this case, all the old values will be re-mapped to match the new values.  Once this is done, your data will be consistent and no special handling will be required.  However, your existing Crash Magic configuration will need to be replaced by a new one that uses the new codes.
  2. Convert all new data to the old values:  In this case, the provider is choosing to pretty much ignore the changes.  The advantage is that there will be no changes needed on your part.  Crash Magic will continue running without change.  However, this strategy will eventually come back to haunt you each time changes are made.  You will also not be able to relate your data to statewide stats.  You will essentially be using a discontinued format.
  3. Convert nothing – just continue adding data:  In this case, the system where the data is being entered probably doesn’t know anything about the data, and most likely, no one is using it for reporting or other analysis.  The type of thing that could occur here is that the value for green in the example above will sometimes be 2 and sometimes be 3.  Hopefully the date will tell which format is being used.  In this scenario, you will need to obtain all data in the old format – import it into the old Crash Magic configuration, and then start obtaining data in the new format and put it into a new Crash Magic database with a new configuration.
  4. Create and maintain a new database:  In this case, the old format is archived and a new database is created to hold the new format of data.  In this case, a new configuration for Crash Magic is needed.  In addition, studies will not be able to span the “break” across databases.

Please contact us once you’ve identified how your data provider is handling this change.  If you are using Crash Magic Data Entry, you have the same three choices as above.  However, we will only support option #1 or #4 and we will assist you in the conversion process.

Converting old Crash Magic data

If your data provider has chosen option 3 or 4 and you would like to bring your old Crash Magic database forward, Pd’ Programming can work with you to convert your old data to the new format.  We will typically prepare a document that describes the changes to the crash form, and how we recommend to handling them when converting data from your exiting database.


Your options:

  • A completely new configuration – To take full advantage of a data source that has had substantial changes, a new configuration may be necessary. 
  • An updated configuration – If most of the fields remain unchanged, but some need updating, a partial configuration may be an option. An example would be the addition of new and useful fields such as coordinate data; an officer narrative; scanned report access; etc. Additions like this that do not involve changing key fields can usually be completed without a full configuration.
  • A new import definition – If it is possible to keep your existing Crash Magic data structure, lookups and logic, then all that is needed is to bring the new data in.  This requires an import definition, but no substantial changed to the rest of the configuration.
  • Conversion of existing data forward – Independent of the option selected above, there will be the question of what to do with your existing data.  The simplest solution would be to simply discard the old data and start with the new.  That is generally not a practical solution.  The most complex is to identify all of the differences between the old and new data and map the old data values into the new database definition.  This is usually the best solution, but takes some time and effort to do properly.
Was this article helpful?
0 out Of 5 Stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we improve this article?
How Can We Improve This Article?