NZ Police Tactical Options Reporting Data

On 30 November 2016, Emmy Rākete requested information from Police under the OIA, including:

Provide all raw data being used in the creation of the biannual tactical options research report for 1 July – 31 December 2016.

OIA request: Tactical options research report | Emmy Rākete

In their response on 22 December 2016, Police refused the request under section 18(e) of the OIA, asserting that the requested information did not exist. They also explained:

a technical fault occurred with the Tactical Options Reporting (TOR) database which has delayed the production of the report on the use of tactical options in 2015. The technical fault has been fixed, however, there are carry-on issues which are still being resolved.

Superintendent Chris Scahill | NZ Police

On 18 January 2017, Police acknowledged that Ms Rākete considered two matters in her request to be outstanding, and extended her request to 20 February 2017.

On 16 March 2017, NZ Police sent a further response, in which they acknowledged that they had been informed by the Ombudsman that Ms Rākete had laid a complaint because Police had not responded to two parts of her request, including the part asking for raw TOR data.

In this response, Police explained that they had refused Ms Rākete's request for data being used in the creation of the TOR report to cover July-December 2016 because no such report was being created, and the data covering July-December 2016 was incomplete.

However, Police also said they had reconsidered Ms Rākete's request for raw data, and released TOR data covering 1 July – 31 December 2016 in the following spreadsheet:

170202 RAKETE 16 11336 TOR xlsx.xlsx

This spreadsheet contains a "Notes" sheet detailing how the export was created and what fields had been removed or recoded:

The export was created using the following search criteria

• Incident start date = 1/07/2016
• Incident end date = 31/12/2016

The following fields have been removed pursuant to section 9(2)(a) of the Official Infromation [sic] Act 1982

• Incident station
• Area
• Reporter Name
• Reporter QID
• Reporter Rank
• Reporter position
• Other Police QIDs
• Subject [name]
• TaserCam Serial No

The following fields have been replaced by other calculated fields pursuant to section 9(2)(a) of the Official Infromation [sic] Act 1982

• Incident date has been replaced by month and year
• Subject DOB has been replaced by Subject Age

The following fields have been removed, pursuant to section 9(2)(a) of the Offician Infromation [sic] Act 1982

• Your [Reporter] Role
• [Subject] Role
• Relevant factors
• Subject Weapon
• Subject behaviours [for all Tactical Options]
• Handcuff Types for all uses of Handcuff/Restraints]
• Technique [for all uses of Empty Hand tactics]
• Reason no warning [for all uses of TASER]
• Other tactic [type] [for all uses of Other tactics]
• Most effective tactic
• Subject resolution
• Staff Injury: type
• Staff Injury By Police: Actions
• Staff Injury By Equipment
• Staff Injury By Equipment: Failure
• Staff Injury by Other
• SRBA: Why Not
• SRBA: Negative How

Caveats:
The records provided in this spreadsheet are derived from the Tactical Options Reporting (TOR) database which records the reportable use of force by Police officers. Each row is a "TOR event" which is the reportable use of one or more tactical options, by one officer, against one individual. Multiple TOR events can occur at one incident. TOR data does not include events where the use of force is associated with a fatality as these events are instead the subject of internal and external investigations.

NZ Police

The Notes sheet also included the following section. I have added emphasis:

While this data could potentially be used to create a biannual report, this data is incomplete and has not been cleaned or coded for analysis or to correct any errors. Some columns have been removed or altered (as outlined above), pursuant to section 9(2)(a) of the Official Information Act 1982, to protect the privacy of natural persons. Given the incomplete and unreliable nature of this data, Police takes no responsibility for its accuracy and correctness, and advises that it is incomplete. Police requests that if you publish this data in any form, you attach a proviso noting that Police have communicated to you that this information is raw data which has not been checked and which is therefore incomplete and unreliable. Furthermore, Police will not be liable for any loss or damage arising directly or indirectly from reliance on the data or information presented in the spreadsheet.

NZ Police

I converted the "Export - Redacted" sheet of this spreadsheet to a CSV using Google Sheets:

170202 RAKETE 16 11336 TOR xlsx.xlsx - Export - Redacted.csv

This data was loaded into Charter using this code:

On 16 September 2017, I requested information from Police under the OIA, including:

TOR data for the 1 January - 30 June 2017 reporting period, in the same format as was released for the July - December 2016 reporting period.

OIA request: Tactical Options Reporting Data January-June 2017 | Brooke Hart

I also asked that Police consider including some information that was redacted from the previous release:

In the data released in March, the following information was withheld entirely "as they may contain free-text (including names)":

• Your [Reporter] Role
• [Subject] Role
• Relevant factors
• Subject Weapon
• Subject behaviours [for all Tactical Options]
• Handcuff Types [for all uses of Handcuff/Restraints]
• Technique [for all uses of Empty Hand tactics]
• Reason no warning [for all uses of TASER]
• Other tactic [type] [for all uses of Other tactics]
• Most effective tactic
• Subject resolution
• Staff Injury: type
• Staff Injury By Police: Actions
• Staff Injury By Equipment
• Staff Injury By Equipment: Failure
• Staff Injury By Other
• SRBA: Why Not
• SRBA: Negative How

I would ask that you consider whether, as required by s9(2)(a) of the Official Information Act, it is *necessary* to withhold all of this information in order to protect the privacy of natural persons. I expect this is not the case, and it would be preferable if only that information which it is necessary to withhold for that reason should be withheld, rather than the entire content of these columns.

I understand that this would likely require significantly more work before the data is fit for release. I would be happy to consult with you regarding this part of my request if necessary, to discuss potential compromises that will allow more of the data to be released without requiring a charge or being refused under s18(f) of the Official Information Act.

OIA request: Tactical Options Reporting Data January-June 2017 | Brooke Hart

On 25 September 2017, a Police employee consulted with me on refining this part of my request. She explained that manually reviewing the fields that had previously been redacted in this way would take a very long time, and proposed a compromise:

in order to facilitate your request, Police are willing to recode some of these variables, so long as the total time required to prepare the dataset remains under one hour (in line with Ministry of Justice guidelines). As such, we would recode variables for which we already have a robust recoding technique established (but which has not yet been applied to this current dataset). This would likely include Subject relevant factors and subject weapon types.

OIA Response | NZ Police

I responded to clarify that I was most interested these columns being included:

• Subject Weapon
• Reason no warning [for all uses of TASER]
• Other tactic [type] [for all uses of Other tactics]

I also said I would appreciate if the "Relevant factors" column could be included if Police had sufficient time.

Police responded again to tell me what additional work they would be willing to do to allow more information to be included in the release:

Based on your response Police are willing to recode the "Subject Weapon" and, if time permits, the "subject relevant factors" fields.

For the "Other tactic" and "Reason no warning" fields, these are solely free-text fields which we do not currently have a recording process for. However due to the relatively low number of cases for each field we believe that we can redact any personal information that may exist in these cells, within the one-hour timeframe .

During this process, it may be necessary to redact additional content in the free-text fields for reasons other than privacy (for example, under sections 6(c) or 9(2)(g)(i)). The reasons for any redaction will be noted in the cells.

Also, please be aware that the content in the "Other tactic" fields are particularly prone to data entry errors. Police will not be investigating nor correcting or recoding any data errors.

OIA Response | NZ Police

On 25 October 2017, Police released TOR data covering 1 January 2017 – 30 June 2017 in this spreadsheet:

spreadsheet.xlsx

This spreadsheet contains a "Notes" sheet detailing how the export was created and what fields had been removed or recoded:

NZ Police

The Notes sheet also included the following section. I have added emphasis:

The export was created using the following search criteria

• Incident start date = 1/01/2017
• Incident end date = 30/06/2017
• Status = Complete

The following fields have been removed pursuant to section 9(2)(a) of the Official Infromation [sic] Act 1982

• Incident station
• Area
• Reporter Name
• Reporter QID
• Reporter Rank
• Reporter position
• Other Police QIDs
• Subject [name]
• TaserCam Serial No

The following fields have been replaced by other calculated, recoded or redacted fields pursuant to section 9(2)(a) of the Offical Infromation [sic] Act 1982

• ID number has been created for this request. This is a unique randomly generated ID reference number
• Incident date has been replaced by month and year
• Subject DOB has been replaced by Subject Age
• Relevant factors has been replaced by multiple varibales [sic] beinging [sic] with "RF:…"
• Most effective tactic has been replaced by Most effective tactic - RECODE
• Subject Weapon has been replaced by Subject Weapon - RECODE
• Taser 1: Reason No Warning has been replaced by Taser 1: Reason No Warning - REDACTED
• Firearm 1: Firearm Type has been replaced by Firearm 1: Firearm Type - RECODED
• Other 1: Tactic has been replaced by Other 1: Tactic - REDACTED

The following fields have been removed, pursuant to section 9(2)(a) of the Offical Infromation [sic] Act 1982, as they may contain free-text (including names)

• Your [Reporter] Role
• [Subject] Role
• Subject behaviours [for all Tactical Options]
• Handcuff Types [for all uses of Handcuff/Restraints]
• Technique [for all uses of Empty Hand tactics]
• Subject resolution
• Staff Injury: type
• Staff Injury By Police: Actions
• Staff Injury By Equipment
• Staff Injury By Equipment: Failure
• Staff Injury By Other
• SRBA: Why Not
• SRBA: Negative How

Caveats:
The records provided in this spreadsheet are derived from the Tactical Options Reporting (TOR) database which records the reportable use of force by Police officers. Each row is a "TOR event" which is the reportable use of one or more tactical options, by one officer, against one individual. Multiple TOR events can occur at one incident. TOR data does not include events where the use of force is associated with a fatality as these events are instead the subject of internal and external investigations.

NZ Police

The Notes sheet also included the following section. I have added emphasis:

This data is incomplete and has not been cleaned or coded for analysis or to correct any errors. Some columns have been removed or altered (as outlined above), pursuant to section 9(2)(a) of the Official Information Act 1982, to protect the privacy of natural persons. Given the incomplete and potentially unreliable nature of this data, Police takes no responsibility for its accuracy and correctness, and advises that it is incomplete. Police requests that if you publish this data in any form, you attach a proviso noting that Police have communicated to you that this information is raw data which has not been checked and which is therefore incomplete and may be unreliable. Furthermore, Police will not be liable for any loss or damage arising directly or indirectly from reliance on the data or information presented in the spreadsheet.

NZ Police

I converted the "TOR Export" sheet of this spreadsheet to a CSV using Google Sheets:

spreadsheet.xlsx - TOR Export.csv

On 5 July 2018, I requested information from Police under the OIA, including:

TOR data for the 1 July - 31 December 2017 reporting period, in the same format as was released for the January-June 2017 reporting period.

OIA request: Tactical Options Reporting Data July-December 2017

On 9 August 2018, after I had queried why Police had not responded to my request within the legislative time limit, they told me:

On the [sic] 24 July 2018 we experienced a system fault with the Tactical Options Reporting database, among some others. This fault saw the database out of commission for a week.

I can advise you that the database is back on line and the request has been prepared and is currently proceeding through the Executive and Legal consultation process and should be released to you shortly.

OIA Response | NZ Police

On 29 August 2018, Police released TOR data covering 1 July 2017 – 31 December in this spreadsheet:

IR 01 18 5190 TOR Data for Release.xlsx

This spreadsheet contains a "Notes" sheet detailing how the export was created and what fields had been removed or recoded:

The export was created using the following search criteria

• Incident start date = 1/07/2017
• Incident end date = 31/12/2017
• Status = Complete

The following fields have been removed pursuant to section 9(2)(a) of the Offical Infromation [sic] Act 1982

• Incident station
• Area
• Reporter Name
• Reporter QID
• Reporter Rank
• Reporter position
• Other Police QIDs
• Subject [name]
• TaserCam Serial No

The following fields have been replaced by other calculated, recoded or redacted fields pursuant to section 9(2)(a) of the Offical Infromation [sic] Act 1982

• ID number has been created for this request. This is a unique randomly generated ID reference number
• Incident date has been replaced by month and year
• Subject DOB has been replaced by Subject Age
• Relevant factors has been replaced by multiple varibales [sic] beinging [sic] with "RF:…"
• Most effective tactic has been replaced by Most effective tactic - RECODE
• Subject Weapon has been replaced by Subject Weapon - RECODE
• Taser 1: Reason No Warning has been replaced by Taser 1: Reason No Warning - REDACTED
• Firearm 1: Firearm Type has been replaced by Firearm 1: Firearm Type - RECODED
• Other 1: Tactic has been replaced by Other 1: Tactic - REDACTED

The following fields have been removed, pursuant to section 9(2)(a) of the Offical Infromation [sic] Act 1982, as they may contain free-text (including names)

• Your [Reporter] Role
• [Subject] Role
• Subject behaviours [for all Tactical Options]
• Handcuff Types [for all uses of Handcuff/Restraints]
• Technique [for all uses of Empty Hand tactics]
• Subject resolution
• Staff Injury: type
• Staff Injury By Police: Actions
• Staff Injury By Equipment
• Staff Injury By Equipment: Failure
• Staff Injury By Other
• SRBA: Why Not
• SRBA: Negative How

Caveats:
"The records provided in the attached spreadsheet are derived from the Tactical Options Reporting (TOR) database, which records the reportable use of force by police officers. Each row is a ‘TOR event’, which is the reportable use of one or more tactical options, by one officer, against one individual. Multiple TOR events can occur at one incident.
During the period of this analysis, TOR data does not include events where the use of force is associated with a fatality, as these events are the subject of internal and external investigations."

NZ Police

The Notes sheet also included the following section. I have added emphasis:

This data is incomplete and has not been cleaned or coded for analysis or to correct any errors. Some columns have been removed or altered (as outlined above), pursuant to section 9(2)(a) of the Official Information Act 1982, to protect the privacy of natural persons. Given the incomplete and potentially unreliable nature of this data, Police takes no responsibility for its accuracy and correctness, and advises that it is incomplete. Police requests that if you publish this data in any form, you attach a proviso noting that Police have communicated to you that this information is raw data which has not been checked and which is therefore incomplete and may be unreliable. Furthermore, Police will not be liable for any loss or damage arising directly or indirectly from reliance on the data or information presented in the spreadsheet.

NZ Police

I converted the "TOR data" sheet of this spreadsheet to a CSV using Google Sheets:

IR 01 18 5190 TOR Data for Release.xlsx - TOR data.csv

The data sets were all loaded together and then combined to be analysed in groups.

I also created a utility function, getTacticUseRows, for easier filtering when looping through tactics for data sets containing derived FIREARM_USED and TASER_USED columns.

Those derived columns can be created using these functions with addDerivedCol:

Using combined data from the second half of 2016 and the first and second halves of 2017:

Rows where the only tactical option recorded was "communication" were removed. I'm uncertain why any events were loaded this way, as the Use of Force Overview - Reporting document says "communication" should only be recorded when used alongside another tactical option.

The TOR data's TACTICS column doesn't differentiate between firearm or taser shows or uses. Because presentation of these weapons are recorded (excluding when they are presented by the AOS or STG), but this is not the case for other tactical options available to Police, I created new derived columns to filter events based on whether or not a taser or firearm was used as opposed to only being shown.

Using combined data from the first and second halves of 2017:

Rows where the only tactical option recorded was "communication" were removed. I'm uncertain why any events were loaded this way, as the Use of Force Overview - Reporting document says "communication" should only be recorded when used alongside another tactical option.

The TOR data's TACTICS column doesn't differentiate between firearm or taser shows or uses. Because presentation of these weapons are recorded (excluding when they are presented by the AOS or STG), but this is not the case for other tactical options available to Police, I created new derived columns to filter events based on whether or not a taser or firearm was used as opposed to only being shown.

Using data for July 2016 – December 2017:

PCA stands for Perceived Cumulative Assessment. It is part of NZ Police's Tactical Options Framework (TOF), and provides a set of categories for police officers to use when making a risk assessment as part of Police's "TENR" (Threat, Exposure, Necessity, Response) risk assessment model, also part of the TOF.

Police released a summary of their Tactical Options Framework under the OIA on 4 January 2017: Tactical Options Framework (PDF)

Perceived cumulative assessment

Your subjective assessment and continuous reassessment of an incident, using the TENR model, based on information known about the situation and the subject’s behaviour. The PCA may escalate and/or de-escalate more than once during an incident.

There are five categories in the PCA, which are represented in the TOF – cooperative, passive resistance, active resistance, assaultive, GBH or death.

Tactical Options Framework | NZ Police

TOR events can involve more than one use of a firearm. For this chart, I looked specifically at the first recorded use of a firearm during a given TOR event.

I only looked at the first instance because, in the few rare cases in which multiple uses of a firearm are recorded in the same TOR event, each use had the same PCA and method recorded:

Because TOR events prior to 2018 excluded incidents where a person was killed, events where police officers discharged a firearm are likely to be excluded from the TOR database. These events are rare anyway, with the vast majority of events being presentation only, I have excluded them:

It's still worth being aware that firearm presentations by the AOS and the STG are not recorded in the TOR database.

When creating the graph, I split the events by district. I put events in the three districts where Armed Response Teams were trialed - Counties Manukau, Wairarapa, and Canterbury - in one group and all other districts in the other group.

I also applied some custom CSS to this chart, to adjust its size and the position of its legend:

Using data for January – December 2017:

Starting with the data covering January – June 2017, NZ Police included "Relevant Factor" information.

Using data for July 2016 – December 2017:

TOR events recorded between 0 and 5 injuries, but only details for up to three injuries were recorded. Each injury's severity is recorded in two separate fields: "treatment required" and "treatment received". The cause, site(s), and type of each injury is also recorded.

Though were were a very small number of injuries recorded as having been caused by "Communication", I excluded these from the analysis under the assumption that they had not been recorded correctly.

I sorted the causes of injuries by the number of events at which a they were used, rather than the number of injuries they caused.

Because the details of each injury are recorded in a separate set of columns, they can't be easily compared across rows. I created a new derived column containing a more convenient way to examine a given event's recorded injuries.

Each injury has a separately recorded "treatment required" and "treatment received". I reduced these to a single reference property for an injury's treatment.

This property used the treatment received, except in cases where Police recorded that a higher level of treatment was required. In cases where the level of treatment required was higher than the level of treatment received, I used the level of treatment required. Those levels are:

1. Refused (treatment received only)
2. Nil
3. Self
4. At Scene
5. Medical
6. Hospital

I also created a derived column containing an array of the causes of each injury at an event, to make it easier to filter down to rows containing an injury caused by a particular tactical option.

I created the graph by looping through each treatment level, injury cause, and row to count the total number of matching injuries. This means if multiple injuries at the same event had the same cause, they would be counted individually.

I created the rate graph by going through the same process as the prior graph, but dividing each column by the number of events at which a tactical option was used. For this process, I had to ignore injuries caused by "Other - not tactic".

Using data for July 2016 – December 2017:

I excluded the "Communication" tactic because it is not a use of force.

I sorted the list of tactics by the number of events at which a they were used.

I created the graph by counting the number of events at which each tactic was used, excluding recordings of firearms or tasers being shown but not used.