Law Enforcement Dispatched Calls for Service
Revised: 9/10/2021
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.
It is not possible to count the number of crimes from the Dispatched Calls for Service Dataset
It is not possible to estimate the number of crimes or offenses that occurred from the Calls for Service dataset. This is operational data that captures the number of times and reasons for public safety personnel being dispatched to a location. Callers may be mistaken and make inaccurate reports, and crimes may not result in dispatches. For example, a caller may report hearing gunshots. A DEM Call Taker would record it as gunshots but it may actually be fireworks. In another example, a car break-in that did not just happen may be reported by completing a police report online which would leave no CAD record.
It is not possible to count the number of calls that came into 911 from the Dispatched Calls for Service Dataset
The calls for service dataset represents dispatched incidents. Related 911 calls will be associated together in ways that are not captured in this dataset. In addition, many calls come in that do not warrant dispatching an officer to the scene. These calls do not appear in this dataset.
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.
Original Call Type helps understand why officers are dispatched.
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.
Final Call Type helps understand what officers were dispatched to.
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.
Code | Definition | Explanation |
ABA | Abated | Officer responded, confirmed the call, and handled |
ADM | Admonished | Officer responded, confirmed the call, and handled |
ADV | Advised | Officer responded, confirmed the call, and handled |
ARR | Arrest | Officer indicates an arrest. Note: Will be different from other SFPD reporting and is should not be used to calculate arrest statistics |
CAN | Cancel | Call cancelled before officers engaged the call |
CSA | CPSA assignment |
CPSA assignment |
22 | Cancel | Call cancelled before officers engaged the call |
CIT | Cited | Citation was issued |
CRM | Criminal Activation | Burglary Alarm calls resulting in criminal activity
|
GOA | Gone on Arrival | Upon arriving suspect no longer on scene. |
HAN | Handled | Officer responded, confirmed the call, and handled |
NCR | Non-Criminal | Arrived on scene and did not find a criminal issue |
ND | No Disposition | Officer determined this call related to another call. The other call would have the disposition for the incident. |
NOM | No Merit | Arrive on scene and Officer determines doesn’t merit further response |
PAS | Premises Appears Secure | Premises Appears Secure. Disposition commonly seen for house alarm calls. |
REP | Report | Officer resolved incident and this resulted in a police report. Note: Should not be used to calculate official number of reports |
SFD | SFFD Medical Staff Engaged | EMS or SFFD Medical Staff Engaged |
UTL | Unable to Locate | Upon arriving suspect no longer on scene |
VAS | Vehicle Appears Secure | Vehicle Appears Secure. |
Per a December 3, 2019 Controllers Office report a 911 call can be broken into 5 discrete segments for analysis:
- 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.
Data users interested in calculating response times should read the full Controllers Office Memorandum for additional guidance: https://openbook.sfgov.org/webreports/details3.aspx?id=2774
It is not possible to determine total amount of officer time spent on a call
Multiple units can be dispatched to a single call. The timestamps in this dataset represent the time when the first unit arrived on scene and the last unit closed the call. It is not possible to determine the number of officers responding to a call from this dataset or the total amount of time each officer spent on a call.
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.
Priority | Definition | Potential Examples* |
A |
|
|
B |
|
|
C |
|
|
I |
|
|
*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.
Priority | Description |
459-A | Suspect is on-scene and the burglary is in-progress; weapons are involved or someone is injured. |
459-B | Suspect recently fled the scene; no injuries are involved, all victims are safe, and the scene is secure. |
459-C | Crime occurred while owner was on vacation; owner reports it after discovering it upon their return. |
Another example using shooting call code.
Priority | Description |
217-A | A non-fatal shooting |
217-B | Interviewing a shooting victim who is no longer on scene, or responding to a witness or other evidence where timeliness matters |
217-C | Responding to information about a shooting that is not current |
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.
In summary:
- 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.
Call Type Code | Suppressed in
Real-time dataset | Suppressed in
Historic dataset | Definition |
805 | Yes | Yes | TRUANCY Calls involving juveniles |
806 | Yes | Yes | Juvenile Beyond Control |
420 | Yes | Yes | Juvenile Disturbance |
Suffix CA | Yes | Yes | Child abuse |
288 | Yes | Yes | Sexual Assault under the age of 15 |
261 | Yes | Yes | Sexual Assault, age 15 years or older |
Suffix EA | Yes | Yes | Elder abuse |
Suffix DV | Yes | Yes | Domestic abuse |
801 | Yes | Yes | Person Attempting Suicide |
802 | Yes | Yes | Death / Coroner |
5150 | Yes | Yes | Mental Health Detention |
100 (except 100V and 100M) | Yes | | Burglary alarms for ADP |
585 | Yes | | Traffic stops |
903 | Yes | | Passing calls (P=City Parking Lots) |
530 | Yes | | Bomb Threat |
531 | Yes | | Suspected explosive device found |
532 | Yes | | Suspicious Mailing |
10-6A | Yes | Yes | 416 for medication |
10-6C | Yes | Yes | Homecheck |
10-6E | Yes | Yes | EOD/EDD (Explosive Detection Dog) |
10-6F | Yes | Yes | Financial Institution |
10-6H | Yes | Yes | Hospital Watch |
10-6J | Yes | | Psych Escort |
10-6K | Yes | Yes | Keeper Assignment |
10-6M | Yes | | Misc. Civil Process |
10-6P | Yes | Yes | Posting |
10-6R | Yes | Yes | 416 for restraints |
10-6S | Yes | Yes | 416 for seclusion |
10-6T | Yes | Yes | Temporary Restraining Order Service |
10-6V | Yes | Yes | Eviction |
10-6W | Yes | Yes | Warrant Service |
For the above call types the following fields will be suppressed:
- call_type_original_notes
- intersection_point
- intersection_id
- intersection_name
- supervisor_district
- analysis_neighborhood
- police_district
- census_tract_geoid
Last modified 4mo ago