Chapter 4: Collecting Data
This chapter outlines elements important for inclusion in an incident database. Users may choose to collect some or all variables as best suits their needs. There may also be codes within a variable that are not useful for individual schools, districts, or states. This model was developed to be as inclusive as possible. The items included below are those that could be used to make a difference in the climate of a school, school district, or state.
The elements discussed in this chapter are broken into four categories, as illustrated in Figure 4-1:
Incidents often involve more than one perpetrator, victim, and/or disciplinary action. Relational databases allow users to record any number of components (e.g., multiple perpetrators, victims, disciplinary actions) without requiring that the number of components be predetermined by the application developer and therefore limited. For example, perhaps a fight occurs involving 10 perpetrators. If the incident database comprises a single data table which contains three perpetrator fields, it will not permit the school to record all the perpetrators' information in the same entry. However, if the database has a separate perpetrator table, users may simply record an entry for each perpetrator, linking the offenders to the incident with the incident identifier field. Similarly, it is likely that there will be incidents that involve multiple victims or that result in multiple disciplinary actions. Allowing for links from the victim and perpetrator modules to the student and staff databases will simplify data entry. Allowing all disciplinary actions for an incident to be recorded will permit complete review of the frequency with which particular penalties are applied and their relationship to future outcomes.
It is useful to collect victim data. Some people would argue that this is unnecessary as the victim did nothing wrong. However, if collected, this information can be useful in identifying patterns of victimization. In addition to their responsibility to take appropriate action against those who cause victimization, schools and districts have a responsibility to support the victims themselves. This includes prevention programs and other actions to prevent discrimination, harassment, and other problem behaviors. Victim data will facilitate this.
In many schools, staff complete one "incident referral" form for each participant in an incident. In such a school for the situation previously described involving 10 perpetrators, 10 referral forms would be generated. As noted above, a relational database will allow the information from all 10 forms to be linked by the same incident identifier.
The discussion in the remainder of this chapter presumes that a relational database linking victim and perpetrator elements to student and staff databases will be used.5 It is critical to treat data on incidents, victims, perpetrators, and disciplinary actions as separate categories of information and create separate "modules" or data tables for each category.6
4.1 Incident Data and Codes
The variables described in this section capture information specific to the incident itself. That is, these variables are used to record what occurred and when. The codes for many variables allow either general or specific information to be collected. The codes are structured so that specific codes can be subsumed under more general codes. This will permit comparability between locales collecting specific information and locales collecting only general information.
Incident Identifier. This is a locally assigned unique identifier (within the school or school district) to identify each specific incident or occurrence. The same identifier should be used to document the entire incident even if it included multiple offenses and multiple offenders. This is one of the key fields that link incident records to perpetrator, victim, and disciplinary action data. In addition to comprising a unique incident code, this variable could include the following elements:7
School Number. This number is assigned by the school district or state for the school where the incident occurred. If the incident occurs during an activity or on transportation that is sponsored by the school, district, or state and not attached to a particular school, use a code that is not already assigned to a reporting unit. For example, 9s can be used to capture these "other" situations. Thus, if the state-assigned school code is a four-digit variable, use the code "9999." If a school identifier is included in the incident identifier, as discussed above, it need not be included separately.8
Incident Date. Use this variable to identify the date when the incident occurred. Allow two digits to capture the day, two digits to capture the month and four digits to capture the year: MM-DD-YYYY. (Consideration of computer operating systems will dictate the format in which the data are stored.)
Time. This variable identifies when the incident occurred and whether or not it occurred during school hours. It is important to record specific information about when an incident occurred. For example, instead of simply recording that an incident occurred during school hours, noting that an incident took place while students were in transit between regular classes or during lunch would make the information more useful. Rather than recording the exact time of the incident, using descriptors may be more meaningful, as the exact time an incident occurred would not be meaningful outside of the school building-while 8:15 a.m. might be "before school hours" on one campus, it could be "during class" at another. Using these descriptors permits greater comparability across schools and districts. Additionally, given that over the course of the school year adjustments to the school schedule do occur (e.g., snow days), while 9:00 a.m. might be "during class" most of the time, on the day of a particular incident it may be "before class." Specific time descriptors will be useful if users are trying to identify when problem behavior is most likely to occur.
Although specific descriptors are recommended, this may not be useful for all schools and districts. For this reason, the coding structure permits the more specific codes that describe exactly when "during school hours" (110-199) an incident occurred to be subsumed under the general "during school hours" code (100). Thus, two locales need not both use specific codes for all incidents during school hours to be comparable.
Location (Where). This variable identifies where the incident occurred. The primary codes for this variable capture whether the incident occurred on or off the school campus. Again, record specific information about where an incident occurred. For example, rather than simply recording that an incident occurred on campus, record that it took place in a classroom. Specific location descriptors will be useful if users are trying to identify where problem behavior is most likely to occur.