Law Enforcement Dispatched Calls for Service

Revised: 9/10/2021

Overview of published datasets

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.

Universe of calls captured in the CAD System

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’).

Diagram 1: Breakdown of Calls in CAD System

Understanding how a 911 call is dispatched

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

Analyzing the Data

Counting the number of dispatched incidents

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.

Diagram 2: All calls received between 10:00pm - 10:05pm

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.

Understanding Original and Final Calls types

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.

A full list of Final Call Type Codes and definitions is stored in the Police Call Types dataset.

Understanding Disposition

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.

Defining Service Time via Time Stamps

Diagram 3: Stages of a 9-1-1 Call

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.

Understanding Priority

The following section is taken from a December 3, 2019 Controllers Office report on response times.

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.

Table 2: Priority Level Hierarchy for Calls with a SFPD Response

Priority	Definition	Potential Examples*
A	Present or imminent danger to life, major property damage, and/or suspect(s) of a crime involving loss of life or serious bodily harm may be in the area and might reasonably be apprehended A major crime scene must be protected A juvenile is missing or involved in sexual abuse or assault An elderly person or any other “at risk” person is missing	Live gun shots Multi-car pile-up Suicide attempt Fight with weapons In-progress burglary
B	There is the potential for damage to property The suspect may be in the area The crime has just occurred	Burglary, perpetrator no longer on-scene Verbal fight
C	There is no present or potential danger to life or property The suspect is no longer in the area The crime scene is protected	Loitering Parking violation Noise complaint
I	“Information-only” No police unit response is required, but relevant information is provided	Bulletin about a permitted event

*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.

Priority vs Original_Priority

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.

Table 3: Example of Priority A, B, or C Burglary Calls

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.

Table 4: Example of Priority A, B, or C Shooting Calls

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.

Privacy and Anonymization

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

How addresses are anonymized

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.

Call Types Suppressed

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