Re-Thinking Emergency Response Metrics


Back
avatar_ef4fddcebc2a_128

OK, I am going to admittedly stray out of my usual “techie” comfort zone and make some observations on PSAP operations I’ve noticed over the years.  I’ve been thinking recently about whether we are really looking at the right performance metrics for PSAP operations.  I’ve also been a big believer that what you measure and make visible is where you focus your efforts.  If you aren’t aiming at the right target you probably won’t hit it.  Let’s take a look at how many, if not most, of us are currently measuring and reporting incident response time.

The metrics typically tracked are shown in the diagram below:

Let’s take a different look at how we look at responses.  At the highest level we can break an end-to-end emergency response into 4 components: 1) discovering the incident, 2) evaluating how to respond, 3) getting the right resources to the right location in a timely manner, and 4) response effectiveness.

Discovering the Incident.  Today we like to look at dropped call rates and time to answer a call.  These are typical call center metrics.  But what we really want to do is shorten the time to identifying the need for an emergency response with the same level of resources.  A theoretical metric is something like “time from incident occurrence to identification per dollar invested”.  It’s really an ROI on our emergency infrastructure investment.  Why look at it this way to essay help?  Typical dropped call rates and time to answer a call assume a static model of a call taker answering a call.  But that misses a huge area of potential improvements.  For example, take the automated fire alarm protocols (“ASAP to PSAP”) gaining popularity.  They are pushing incidents directly into CAD, reducing the need for call taker intervention.  Or what about advances in telematics or even wireless health monitoring?  We already have pilots of home health monitoring systems that will automatically notify doctors ofcardiac dysrhythmias, dangerously low levels of blood glucose, or other conditions being monitored.  Those could be piped directly into EMS dispatch when pre-determined thresholds are met.  Our current metrics don’t really get us to look at the broader picture of incident identification, instead we focus on the time from a call being made to answered.  There could be a significant time gap between an incident occurring and a phone call being initiated.

How to Respond.  Currently an incident is evaluated by a call taker who triages the call and then either dispatches emergency resources or involves a separate dispatcher. Currently we look at time to dispatch or call processing time.  These metrics also only show half of the picture.  For example, you may get 30 calls reporting an accident on the highway.  The first one is a quick call to report the incident, the next 29 callers are all reporting the same thing and are handled rapidly.  The result is a quick time to dispatch and very low call handling times.  You’ve done a great job right?  Maybe not.  Your normal staffing level is probably inflated due to a large number of daily highway calls.  .  In reality, you should be triaging those 29 calls automatically.  For example, you may identify the calls as coming from the same area and have an automated process that after the second call from the same region recognizes there is an accident dispatch code in effect in that area and sets up an automated answering system (interactive voice response / IVR) stating “We are aware of a crash on XXXX, units are enroute.  If you are calling to report that incident and are not directly involved in or have stopped at the incident, please hang up.  Otherwise you will be immediately routed to the next available emergency operator at http://samedayessays.org/. We thank you for your report.”  A theoretical metric may be “% of calls answered requiring a unique response or incident vs total calls received.”  You are now measuring your rate of actually adding value to a caller and response. This metric also takes into context the broader concept of citizen training on when to call 9-1-1.

Dispatching the Right Resources at the Right Time to the Right Location.  Let’s theorize on what is possible here.  Currently we receive a call, evaluate what is needed, look at the resources available, and then dispatch via the radio or silently, via mobile CAD.  But we really know what resources are available before the call taker even answers.  Why not look at algorithms that start getting resources ready as soon as a call is received.  If you are doing a good job on the % of calls handled that require a unique dispatch, you can at least start giving an immediate heads up to law enforcement (who responds to the majority of incidents).  See who is closest and available and maybe send a “heads up” page.  At some point then bridge the unit that was given the heads up right into the call to reduce the need to repeat the information gathered from the caller while also providing the responder with ambient noise cues that are hard to convey in relaying a message.  The metrics here involve examining either the time from incident identification and assignment of a resource or the time from incident identification to a first resource beginning to respond.  The concept of when a dispatch occurs, or time to dispatch, is somewhat open to interpretation.

For another example, let’s look again at the remote monitoring scenario.  If you have a heart monitoring alarm going off, and know that the patient is a 75 year old with a specific medical history you can make decisions in the PSAP that can have a huge impact on the incident response time and cost.  Step with me into the time machine a bit and imagine you have a database of nearby trained EMTs.  A quick page to EMTs in the area requiring a response on availability could result in a trained resource on the scene far quicker than an ambulance response and at far less expense.  What makes this possible?  First, accurate data on the incident (how to access the patient’s home, does he require basic or advanced level care, is he unconscious and in need of transport to a hospital, etc).  Second, a more complete picture of resources available is needed research papers (what EMTs, paramedics or nurses are in the area and available to respond, and the ability to easily push data on the patient to them).  Finally, thinking about the problem differently.  The metrics here are broader than we think of in a PSAP.  Our PSAPs measure how quickly they dispatch a resource (not even necessarily the right one). The resources themselves measure how long it takes to get there and (sometimes) whether they were effective.  Our metrics don’t really incent us to look at what other resources we should have been considering.

Response Effectiveness

The final, and most important, step in the process is measuring how effective the response was.  Was a crime averted?  Was a patient saved?  Traditionally this feedback loop has been a major gap for PSAPs, however, lack of that end-to-end visibility causes us to implement sub-optimal processes.  Maybe dispatch should be doing more to ensure the Emergency Room is prepared for the incoming patient.  How?  Maybe we should be pushing the caller’s medical records securely to the appropriate hospital.  Maybe we should be automatically alerting the caller’s primary care provider to the emergency and where the caller is being sent. Maybe the 10th time in the week we get a call from one of our frequent flyers should really be a social worker dispatch or even a taxi?  Are there increased liabilities?  Maybe.  But I do know that unless we look at the problem through the right lenses we’ll miss opportunities to improve the entire system – and that includes changing legislation around liability.

We need metrics that evaluate outcomes and look at the holistic system – not just getting an ambulance, fire truck and police unit on site within 4 minutes.  The diagram below shows a citizen’s perspective on the end-to-end response process we should be striving to maximize.

ResponseTimesTotal

Leave a Reply

Your email address will not be published. Required fields are marked *