While I can appreciate the scenario of multiple callers calling in the same vehicle accident once it is already reported, with a new unrelated 9-1-1 call waiting in the mix of the queue of these other calls, you risk the danger of this predictive technology associating a call that may be in the geographic vicinity as a duplicate call and giving it a lower priority. It is not uncommon, especially in large metro-plex areas, that there can be several 9-1-1 calls within close proximity to each other, but be unrelated to each other, therefore just as important. At my previous PSAP, we experienced this on numerous occassions, and at time, have mistakenly classified nearby incidents, and in particular, traffic accidents, as the same scene, when they in fact are not the same. Additionally, I would not want a PSAP to fall to public scrutiny when a citizen complains that technology decided that their 9-1-1 call was more important than another call and classified it as a lower priority, and delaying that call being answered by a telecommunicator. I think there needs to be more discussion with the PSAP community regarding how these predictive systems are designed before they may be accepted across the board.
This Blog is also available as an Audio Podcast HERE
As we wrap up the events of 2012, I can’t help but look back on the fast-paced evolution that is taken place in the Public Safety industry. In the beginning of the year, NG911 was officially conceived when it was promulgated by the Next Generation 911 Advancement Act of 2012 that was part of the Middle Class Tax Relief and Job Creation Act signed into law by the President in February.
By strange coincidence, just nine short months later, NG911 networks are being born around North America with texting to 911 being touted in several areas around the country. With these new emergency services networks being built, and ready to accept the extremely important “additional data” objects that originating networks can easily provide, the days of matching telephone numbers with street addresses in some archaic database that cannot be efficiently and affordably updated, are quickly going to enter their sunset phase.
Some naysayers said it would never happen, or be years into the future, and banked on the continuance of the overburdened backend architecture of the legacy 911 network. Others, took a completely different tact and turned to technology that was not necessarily innovative in its nature, but completely new to public safety networks. New mechanisms of dealing with the “Big Data” available in an emergency situation required a new way of thinking that was essentially foreign to this environment. Fortunately, enterprise businesses have been dealing with the concepts of “Big Data”, whether they knew it or not, since corporate networks came into existence.
“Your call will be answered in the exact order it was received”
Whoever came up with that concept had a very myopic view on business trends.
Unless you are a radio station giving away tickets to the latest concert, “the exact order in which your call was received” is probably the most useless business strategy when dealing with customers. Public Safety also has its share of customers, however those customers are usually calling with life-threatening issues. It’s easy to understand, how in the past, choosing the most important phone call out of a group of 10 would be nearly impossible. All of the buttons on the telephone flash at the same rate, and the ringer on the phone for each line is identical. There is no indicator that is able to say “Hey! I am more important than the rest!” Given that scenario, potentially the fairest mechanism was “your call will be answered in the exact order it was received”.
Think about that for a second. That argument is really no longer valid, as the business world is full of analytical research. Businesses act a certain way based on statistical data that’s available. It could be consumer shopping habits around a holiday, web browser history and associated keywords, or just about anything else that’s measurable or recordable.
“Your NG911 call will be answered according to priority”
Here’s where the value of additional data, and Big Data, come into play. A classic example that’s commonly used when talking about intelligent call routing in an NG 911 environment is, a motor vehicle accident on the highway is generating 10 or more simultaneous calls into a single PSAP. These calls are identified based on two things. First, their origination network is the cellular network. Secondly the geodetic coordinates of the device match the coordinates of a motor vehicle accident already being worked.
Callers 2 through 10 are most likely calling about the motor vehicle accident. If there are no additional calls in queue, these can be answered “in the exact order in which they were received” following the legacy standards already in place.
But, caller 11 shows up in the queue, and is originating from a landline telephone registered to a residence across town.
Caller 11 is most likely NOT calling about the known motor vehicle accident, and therefore is escalated in the queue, or assigned to a call taker who has been reserved for when these conditions have been met.
Those of you who operate enterprise call centers, can already see the pattern developing here. While legacy public safety vendors are busy spinning their wheels trying to figure out how to deliver multimedia sessions to emergency call takers, folks like Avaya have figured that out years ago, and in many cases pretty much invented the call handling functionality, or at least were the first to implement it.
It’s called workforce optimization or WFO, and it’s a common function found within the contact center products. We already know how to deal with “Big Data”, analyze it, and use it to efficiently route to call taker resources in large multisite networks. Although some may say calling a large retailer to complain about your refrigerator delivery carries nowhere near the urgency or resiliency required for public safety, and while I agree there is a significant difference in the nature of the calls, I also need to remind you of some simple facts.
Most recently during hurricane Sandy in the Northeast, the utilities infrastructure was badly damaged with countless individuals out of service. For those citizens who had emergencies, in many cases those calls went to fast busy or unanswered as the legacy 911 network became oversubscribed and the calls went into a black hole “in the exact order they were recieved”. On the other hand, if you called Delta Airlines to find out if your flight was delayed, you were routed to a resource that could provide you with information or assistance. You might also be able to call your power provider, and based on your customer profile, you may be presented with a power restoration estimate.
The bottom line is that intelligent call handling, offloading calls that matched a particular pattern, and looking at the “Big Data” associated with sessions, the network can dynamically fine tune it’s routing functionality to ensure that “Your call will be routed to the Best Resource, in the exact order in which it was received.”
While doing some research on this topic, I ran across a great article by colleague of mine, Kathy McMahon, who was the Technical Services Manager for APCO International. If you are looking for a nice read on the topic of GIS, take a look at her article from 2010 in Law Officer HERE.
Of course, getting that data into the Emergency Services IP Network is required, but fortunately the one thing we have understood for several years, is how to share data and collaborate across disparate networks in a secure and resilient manner.
She also confirms a point that I also feel very strongly about, “[although] the conventional concept of civic address validation will continue to be used for NG9-1-1. The terms ANI, ALI and MSAG will go away because their functions will be replaced by GIS databases and a new location validation function (LVF). The GIS data, once validated, will provide location information that will be used for routing emergency calls to PSAPs. All of these elements working together will form the new emergency call routing function (ECRF) that’s a critical component of NG9-1-1.”
My crystal ball says in 2013 “the NG911 adoption rate will be unprecedented in both speed and reach and in addition to Public Safety NG911 ESInet deployments across the US, you will see Enterprise networks providing Big Data to this new eco-system of information.”
Enjoy the New Year Holidays, and remember to check out my colleague Guy Clinch’s new Podcast “AVAYA Tech Talk” available on the Avaya Podcast Network.
Want more on E9-1-1? E9-1-1 Talk Podcast
Subscribe to my weekly E9-1-1 Talk Podcast here
Thanks for stopping by and reading the Avaya CONNECTED Blog on E9-1-1, I value your opinions, so please feel free to comment below or if you prefer, you can email me privately.
Public comments, suggestions, corrections and loose change is all graciously accepted
Until next week. . . dial carefully.
Be sure to follow me on Twitter @Fletch911
It's certainly useful to look ahead and see how NG911 might improve incident reporting. But the concepts and techniques being used by commercial companies might not be applicable to public safety communications centers. There are some critical differences. First, 911 calls represent the most urgent type of communications, far different than a traveler's inquiry about an airline flight. Second, the interactions between caller and dispatcher are enormously short-lived. And lastly, and perhaps most importantly, the calls are entirely random and completely unpredictable. It's this last quality of 911 calls that makes them entirely unsuitable for predictive technology. For each time the NG911 software "intelligently" pushes a 911 call to the top of the incoming queue based on location, another 911 caller located near an existing emergency will be stuck at the bottom of the queue. The real solution is to more quickly answer all 911 calls by routing them to a larger pool of calltakers. Fortunately, NG911 has this capability, tooÃ¢â¬âif comm centers can learn to cooperate.
Lisa, you raise an excellent point. Let me clarify a bit. I agree with you completely that there is little hope for a completely autonomous routing engine making the right decisions all by itself in an emergency environment. But I will stand on the fact that there are (or at least WILL BE) specific indicators that can be used to better triage call incidents. Maybe a better way to say it is never to 'downgrade' a call, but give the opportunity to UPGRADE a call based on information present with the call. I look at this in the same way that Run Recommendations are made based on unit availability and location. The system provides a recommendation of the most logical unit to the dispatcher based on specific criteria. Another example is a language indicator present in the NG SIP Header, I need a call taker that speaks Spanish, or French, or ASL, based on this users profile. I may have a resource in another part of the network with that matching skill set, and I can 'borrow' them, or bridge them in for translation service assist. Or take the information available from OnStar. There are computer models that can take that data, and predict with 80% accuracy or more, the probability of injuries based on the Delta V, the position of the occupant, and the crush zones that have been activated. Imagine the time that could be saved if you had information telling you there is a 90% of severe lower extremity damage. The helicopter, the ER staff, and the entire system can now become aware, and provide better overall handling. I agree that it will never be a perfect solution, and call taker training and override will always be a critical factor, but think of the increased efficiency that can be gained knowing 'the big picture'. Call takers with specific skill sets can have calls that best use those skill sets routed to them, while others take the load off. At the end of the day, there are only so many lines in, and so many seats to answer the calls for help. I think we can do a better job than 'the exact order that your call was received'. Thanks for your comments, and I also hope there is great input from the PSAP community in the design and validation of any routing 'advice' that the system provides. Have a great New Year, Lisa, and thanks for all that you do for the industry!
Gary, You are absolutely correct. Looking at PSAPs from a regional level would allow the collaboration required to dynamically expand and contract a PSAP 'size' given existing events. Again, this all falls back on the 'big data' that needs to be examined, validated, and acted upon. As with any system, garbage in, garbage out. Thanks for the comments!