Using Integration to Create a Unified Emergency Mass Notification System
Overview
Location: St. Louis, MO
Campus Type: Urban
Enrollment: 14,000+
Faculty: 13,000
Campus size: 4,625 acres
Number of buildings: 6 campuses
Washington University in St. Louis was looking for a comprehensive, unified emergency mass notification system that it could use to alert its campus community both quickly and easily. With several segmented programs already in place, it was essential that the new system also allow for integration across the board.
Mark Bagby, director of emergency management at Washington University in St. Louis, discusses the school’s unique challenges and solution.
Challenge
Identifying the Emergency Notification Gaps
Prior to 2007, we had a product that handled text and email. That was troublesome because you could only opt in; we only had about 10 percent of our folks that would opt in. After that we switched to Everbridge, which gave us a little more flexibility; we were able to tie it in to our Human Resource database and our student information system database. From that point the system became opt out. That was our way of reaching the campus community on an individual level (text, email, or voice call.)
We also had our outdoor warning sirens, which we could set off with voice or siren tone. Our county would set them off for severe weather. For a while that worked well, but we constantly would get feedback (every time we did a test or had an activation) from faculty, staff, and students that they didn’t get the alert—I was in the basement, or I was in class and the professor said to turn off your cell phone. Every time we have an activation or a test we use that feedback to see where are the gaps, and where can we do better.
Segmented Programs vs. One Unified System
Our main challenge was that all the programs were segmented, so you had to go into each system, log in with your credentials, go through a protocol to send an alert. When we did that with the dispatchers, sometimes it would take up to 30 minutes. And that was a big problem. We were looking for a way to condense the system and get down to an easy button approach—one dashboard, easy to use, but also have the security. The Alertus system really allowed us to do that, to package everything under one dashboard, lock down the security levels, and give folks easy access.
Solution
Integration with ThreatWatcher
We have Alertus ThreatWatcher watching the NOAA weather feed for keywords—St. Louis County, tornado warning. If it matches that criteria, then it automatically activates our system, sets off our beacons, our text-to-speech devices, any public address that we have tied to it goes off, the desktop pop-ups, and our cable TV override. The emergency alert takes over the TVs for three minutes. Through the Alertus to Everbridge API, it sends an email to everybody in the campus community.
Each year we get multiple interactions for tornado warnings. We’ve also used the system before for a campus closure. We had snow and ice and wanted to close the campus early. We use the system to help get the message out for that. We tie the system and activations to our emergency website as well. As soon as we send out a message, it goes up on our website. Before, public affairs had to go and manually put that in, which could lead to anywhere from a 5–30 minute delay. They would have to get the message, log into the system, post the message, and in that time people were going to the website and seeing that there’s no emergency.
One thing we’re working on right now with Alertus is with the ThreatWatcher program to develop a polygon mapping application. St. Louis County is quite large; we’re over notifying our folks at times because we’re keying in on those key words. We’re beta testing with Alertus an enhancement that draws a polygon around campus and puts a 10-mile buffer around it. So if the National Weather Service polygon touches our buffer, then the system would activate. That should reduce the tornado warnings up to 50 percent in theory, based on previous storm tracks. When we look at the historical data, just in this past year we’ve had about 12 warnings. Ten of them would not have set off our system with this new product.
Leveraging Existing Systems and Equipment
We’ve got an app on campus that a lot of folks download. It gives them the menus for the dining hall, the transportation tracker, and we’re looking to see whether we can do push notifications into that app. There are plenty of apps out there that you can buy to notify your campus community, but this is one that a lot of the students and employees already download. So we’re seeing whether we can leverage that to send out an alert, much like our website, that would do a push notification to their phones or tablets.
Why buy another product for them to download that would only be used for emergencies. Why not leverage some of the tools that they use on a daily basis. The same thing with the desktop pop-ups. They’re really great because people are already using the computer, so it’s just a piece of software in the background. They can go about their day-to-day business, and when we issue an alert, it pops up there. The same thing with our digital signage. We allow all the departments to decide what type of signage they want. They just have to use a common software so that we can overtake that signage in an emergency. Again, it’s leveraging the tools that we have already available. We’re not spending extra money for extra devices.
Conclusion
We have six campuses. With the desktop pop-up software, we have six different clients, each specific to the campus, so that we can segregate the message. If there’s only an emergency on the medical campus, then we can only set off those desktop pop-ups, those beacons, those digital signboards. We did the same thing last summer with the students, where they can now download the client as a student file onto their personal machines.