Law Enforcement Dispatched Calls for Service
Two datasets are provided to the public that cover Law Enforcement Dispatched Calls for Service.
- A Closed Call dataset that is updated once every 24 hours and only includes dispatched calls that have been closed. This dataset covers all closed dispatched calls from March 2016 until the present. This dataset is best used for analyzing historic trends
- A Real-time dataset that is updated every 10 minutes with a 10 minute lag. It includes dispatched calls that have closed in the last 48hrs and any dispatched calls that are still open. In general, the time frame of this dataset is the last 48 hours. However you may see exceptions where an open call is outside this 48 hour window. This can occur if a case is reopened to update certain information. This dataset is best used to looking at real-time dispatched call activity.
The Department of Emergency Management operates San Francisco’s 9-1-1 Call Center and Computer Aided Dispatch (CAD) System which manage all emergency (Police, Fire, Medical) incidents that occur in San Francisco. DEM processes over 1.2 million calls per year, on emergency 9-1-1 and non-emergency lines and via land-line, cell phones and texts. All calls made to the 9-1-1 center are recorded, and all emergency calls and most non-emergency calls are logged in the CAD System that DEM maintains as CAD records. These calls result in a little less than 1 million separate CAD records, as sometimes multiple calls are combined into the same record and some non-emergency calls do not result in a record.
Slightly less than half of these CAD records are dispatched to law enforcement, 15-20% are dispatched to Fire or Emergency Medical Services, and the balance are records of calls that did not result in a dispatch. These non-dispatched calls can generally be broken into the following categories
- Accidental or non-germane calls - Over 40% of 9-1-1 calls are either accidental or otherwise not for police/fire/EMS dispatch.
- Information Calls (“I-Priority”)
- Information Broadcast - Some incidents are broadcast over the radio to police units, but not assigned to have a unit respond. These “Information” calls are for things like a reckless driver in an area where there is not a specific location, but the officers should be on the look-out for something. No CAD record is created
- Advised calls - Certain calls are more easily reported through other methods and do not require a dispatched officer. For example, a call about an auto break-in may result in a dispatch depending on circumstances, but usually a dispatch is not required and it is more convenient for the victim to file a report online, with 311 or at a police station. A CAD record is created, but no police unit is dispatched.
- Calls transferred to other jurisdictions - Depending on circumstances a call may be transferred to another jurisdiction to be dispatched and would not be recorded as a dispatched call in SF DEM’s system.
In addition to CAD records created as a result of calls from the public, public safety personnel in the field generate over a half-million additional CAD records annually known as ‘On-View’ calls. These records include documentation of administrative status, as well as incidents identified by personnel in the field. On-View records related to suspected incidents are included in this dataset. Records documenting administrative tasks do not appear in this dataset.
This dataset contains calls dispatched to the Police, MTA Parking enforcement, Sheriff’s Office, and other law enforcement agencies. The majority of calls are dispatched to the Police. Many Sheriff calls for service are not handled through DEM’s CAD system. Only Sheriff calls dispatched by DEM (from Turk St or SF General Hospital) will appear in this dataset. Only calls that have been dispatched are included. Each row represents a separate incident DEM dispatched law enforcement to or an incident a law enforcement officer self-initiated (‘On-View’).
A 9-1-1 call from the public is generated in the 9-1-1 call handling system, and immediately logged in the CAD System. A 9-1-1 call taker immediately characterizes the call as a Police, Fire or Medical incident, categorizes the call, and assigns a priority level. If it is a law enforcement call, the record will be routed to a law enforcement dispatcher based on the location of the call. The dispatcher will assign a unit based on the location and priority of the call. Depending on the severity of the call multiple units may respond. Based on information from the responding unit call priority or call type may be adjusted. When the final unit assigned finishes, the call is marked closed. The dispatcher then assigns a disposition to the call.
On rare occasions the call may be reopened to update call information, resulting in a later than average close time
Each 9-1-1 call received that is dispatched is assigned a unique ‘CAD number’. On-View Calls from law enforcement officers in the field are considered dispatched as well and are likewise assigned a unique cad_number. Each row in this dataset is a unique CAD Number. The number of rows represents the total number of separate incidents law enforcement was dispatched to. It is not possible to identify the number of unique calls that came into 911 from this dataset. Only the number of dispatched incidents.
A single event, such as a gunshot, could generate multiple 911 calls. Multiple calls of the same event are grouped together by DEM Call Takers to the best of their ability. For example, a DEM Call Taker receives a call reporting gunshots. They notice a prior dispatched call (ex. CAD # 10004) that recently came in at the same intersection also reporting gunshots. They associate this new call with that existing call in the systems. In the Police Dispatched Calls for Service dataset these two calls would not show up as two separate rows in the dataset. Only a single row for CAD # 10004 would exist. It would not be possible tell that two calls came in reporting this incident.
DEM Call Takers do their best to associate calls for the same incident to the first dispatched call. However, if calls come in simultaneously, separate DEM Call Takers may each dispatch calls. This would generate multiple CAD #s (and multiple rows in the dataset). For example, if two calls came in simultaneously about an assault two CAD #s would be generated (CAD #10001 & 10002) As the incident progresses Dispatchers can associate the calls together if they believe separate dispatched calls are related. You can identify these calls in the dataset using the DUP_OF_CALL_NO field, which would be populated with the same original CALL_NO (CAD #10001). If a call was not associated by a DEM Call Taker, the DUP_OF_CALL_NO field would be blank.
These call associations are done for operational reasons. It ensures that DEM Call Takers and Dispatchers have a way to identify all the units responding to particular incident. This allows them to appropriately allocate additional units as other calls for the same incident come in. It is not a perfect system and there is no later cleaning or validating of the data. Calls that are actually related to a single event may not be marked as related.
DEM Call Takers, dispatchers, and law enforcement officers in the field will label calls using predefined Call Type Codes (call_type_original) and which has an associated definition. The DEM Call Taker has the option of overriding the default definition with additional context/notes to further refine the Call Type. Call_type_original_desc will contain the default Call Type Code definition and call_type_original_notes will contain any notes a dispatched may have made. This information is not standardized.
As a call progresses new information may be uncovered that suggests the original call type code is not accurate. In these cases the Call Type code may be updated to a more accurate Call Type Code, although if law enforcement personnel are already on scene this update may only happen if it serves an operational requirement such as the need for additional units. These updates may happen multiple times. The Final Code chosen will be indicated in the call_type_final column.
Every call when closed is given a disposition by the responding unit. This disposition is entered by the dispatcher into CAD. Data users of the disposition field should know that the disposition definitions are broad and are used differently based on context of the situation. Dispositions are provided by the last officer to clear the scene. The specific code provided depends on the context and what the specific officer was doing.
Disposition provided for informational value only. They should not be used to calculate statistics. For example Disposition Code ARR will provide different estimates for the number of arrests made compared to official SFPD statistics.
- Answer Time - This interval measures the time between when citizens dial 911 and wait for the call to be answered by a DEM call taker. It is not possible to determine answer time from the Calls for Service dataset.
- Intake Time - This interval measures the time between when a DEM call taker receives the 9-1-1 call to when the call taker enters the call into the queue for dispatch. This is the difference between received_datetime and entry_datetime.
- Queue Time - This interval measures the time between when the call taker enters the call into the queue to when a dispatcher dispatches the call to a unit(s). This is the difference between entry_datetime and dispatch_datetime.
- Travel Time - This interval measures the time between when the call is dispatched to a unit(s) to when the first unit arrives on-scene. This is the difference between dispatch_datetime and onscene_datetime.
- Call Duration – This interval measures the duration of the call from the time the first officer arrives on the scene until last officer closes the call. This is the difference between onscene_datetime and closed_datetime.
The report further classifies two methods of viewing response times
- “SFPD Response Time” refers to the combined Queue and Travel Time intervals, representing the phase in which the SFPD becomes aware of the call even if unable to be dispatched. There are many reasons a call may not be immediately dispatched, including no available units or officers prioritizing other work activities on their shift. This is the difference between entry_datetime and onscene_datetime.
- “Response Time” refers to the segment from when DEM first becomes aware of the call to when a police unit first arrives on scene. This time segment reflects the wait time experienced by the citizen. This is the difference between received_datetime and onscene_datetime.
DEM uses a priority level hierarchy to designate the urgency of calls requiring a police response. Table 2 provides a definition and potential example of the four priority levels used in San Francisco police response.
*Please note these are generalized examples; subtle cues or situational factors may cause the dispatcher to assign a different priority level than the one identified here. The priority level assigned by the call taker may be also changed by the dispatcher once more information becomes available.
While priority levels are automatically assigned by the system based on the initial call code or call type, DEM dispatchers may manually update the priority at any time during the life of a call. Below are three examples of a burglary, each of which would be assigned a different priority but be classified with the same burglary call code.
Another example using shooting call code.
While the system would automatically apply a Priority B to all three calls described above, the call taker or dispatcher may “upgrade” or “downgrade” the priority based on the call details. The PRIORITY used in the dataset is the final priority level recorded at the close of the call.
The release of this data must balance the need for disclosure to the public against the risk of violating the privacy of those individuals present within the dataset. As such, the dataset is subject to several privacy controls to ensure anonymity for all persons within the data.
- 1.All incident locations are shown at the intersection level only.
- 2.Call Types where privacy of individual requires additional protection have certain fields suppressed. Including:
- 3.All location fields
- 4.Call Type Original Description field
- 5.Certain additional call types have data suppression applied in the real-time dataset for officer safety reasons
All Calls for Service locations are shown at the intersection level only. Records are masked to intersections to minimize the risk of re-identification to an individual. Intersections used in the masking are associated with either 0 or greater than 11 premise addresses. A premise address is a specific place of work or residence.
Geographic boundaries such as Supervisor District or Analysis Neighborhood included in this dataset are assigned based on the anonymized addresses. This can result in minor differences between reporting done off the raw non-anonymized data and the public data.
For example, the true location of call number 1234567 occurs in Supervisor District 1, but is near the boundary between Supervisor District 1 and 2. The nearest valid intersection exists in Supervisor District 2. The open dataset would assign Call Number 1234567 to Supervisor District 2 and internal DEM reporting would assign Call Number 1234567 to Supervisor District 1. For large boundaries like Supervisor Districts or Analysis Neighborhoods the impact is minimal. However, it is not recommended to analysis anonymized addresses by smaller boundary files like census tracts or blocks. Due to their small size there can be large variation between the count of incidents based on the actual address information vs the anonymized addresses.
Please note that many incidents appear in both the Calls for Service dataset and the Police Incident dataset and if visualized will have different anonymized locations assigned. This is due to many factors: calls originating from a different location, a general location being provided to 911 operators, or later refinement of incident location during process of filling out an Incident Report.
SFPD and DEM have determined the following call types to be sensitive and are subject to data suppression.
For the above call types the following fields will be suppressed: