Archive for the ‘PublicWarning’ Category

You have been warned

Posted: May 28, 2013 in PublicWarning
Tags: ,

A post by Jim Garrow on his The Face of the Matter blog got me thinking about a simple lesson that all public safety personnel could learn from the National Weather Service and getting our heads out of our collective silos.  Jim speaks about his severe disdain for the term “Shelter-in-Place”, a term likely foreign to 99% of the population prior to its use during the Boston manhunt.  Jim makes some very valid points in his post that I will not rehash here as his post is really worth the time to read.

What I do want to hit on here is how the use of plain and honest language should be considered when communicating with the public but most importantly when communicating warning information.  A significant deal of research has been applied to the area of warning language by the National Weather Service over the years.  For anyone that isn’t familiar with this, you will find that in the last several years warning products have started to use terms like deadly and history of destruction.  As the public became complacent about things like tornado warnings, it was critical for the NWS to provide some context to these warnings to differentiate a tornado on the ground that has just leveled towns from a vague tornado signature detected only on radar.  As evident from the public response to local storms this is working.

Let’s take this one step further however and go just a bit beyond basic warning messages.  People always use historical context when considering how they will respond to basic warnings messages.  For example, I live and work in a community that is no stranger to riverine flooding.  The community is hard and salty in this regard and very unlikely to evacuate in mass due to a familiarity with the threat.  When the big storm comes it is important to provide perspective to them regarding flood depth of historic storms compared to the forecast as well as exactly what they should expect thus allowing them to make an informed decision. Mind you that I do not advocate sensationalism in any form but rather honesty.  A great example of this is in the form of language used by one of my favorite NWS personnel during Sandy in his now somewhat infamous personal plea:


What is important here is to realize that Gary provides some degree of historical context, he appeals to emotion as well as logic and above all else he is honest.  Think about this the next time that you must craft a warning or recommend a protective action.  Do you want to throw out a term that few understand or do you want to show yourself as a person, be honest and potentially save far more lives.


IPAWS Adoption

Posted: January 23, 2013 in IPAWS, PublicWarning

IPAWS has been operational for some time now however adoption by alert originators has been somewhat slow.  This infographic represents the current adoption of IPAWS within the United States. You can find a full list of those agencies currently using IPAWS or in the application process at: If you haven’t adopted IPAWS yet, we would love to hear from you and learn what barriers you are facing.


An emergency notification system that is deployed with a primary mission of providing notifications to the public has significantly more considerations in system selection than a system geared toward internal notifications.  There are several reasons for this but the single most significant is that we must consider two types of messages that will be delivered – those for routine emergencies as well as those for critical events that require immediate action to protect life and property.

Routine Emergency Notifications
We can think of routine emergencies as those that occur daily or weekly that we would like to make the public aware of.  This may include a major road closure, significant weather event, boil water notice, or even a notification that siren systems will be tested.  For these systems we must determine what the most effective method both by penetration and cost to disseminate our message will be. Similar to an internal notification system, we will want to consider the following notification mediums as primary distribution channels:

  • SMS (Text Message)
  • Email
  • Pager
  • Telephone

Most notification systems that are available in the mainstream market provide these distribution channels and the public has generally come to expect that level of availability within an opt-in system.  In addition to this basic feature set, I highly recommend that organizations also consider a system capable of delivering messages via fax.  Many businesses and new media desks may be very interested in receiving notifications from your organization however it is quite likely that the most efficient method to reach them may be by a traditional fax machine.  Your notification system should also be capable of publishing your messages to your organization’s website as well as to social media accounts such as Twitter and Facebook.  These additional distribution channels can substantively increase both the reach and relevance of your message.

Critical Event Notifications
Notifying the public of a critical event that requires them to take immediate protective action calls for activation of the Emergency Alert System (EAS).  Because of this you will want to ensure that any system utilized for delivering these messages is capable of triggering EAS.  Unfortunately, very few notification systems provide for the direct – end to end – connection to broadcasters.

Although I generally attempt to avoid direct vendor mentions, one vendor that does provide such a system, including the interconnecting infrastructure, is Communications Laboratories’ EMnet system. This package places equipment at each activation point as well as each broadcaster and connectivity is achieved using internet as well as satellite links between each point. It is important to note however that while this system does an excellent job at activating EAS, it does not provide for the other distribution channels that we have addressed above.

The advent of the Integrated Public Alert & Warning System (IPAWS) does however offer a mechanism and infrastructure for many notification systems to trigger an EAS activation. Utilizing the internet, a notification system can push a message formated in the Common Alerting Protocol (CAP) to federally maintained servers that will then redistribute the message to broadcasters and select other partners. The IPAWS program is still under development at this point however a timeline has been established by the FCC to require broadcasters to obtain equipment capable of receiving messages from the IPAWS server.

Content Targeting
Depending on the size of the jurisdiction, some thought should be given to ensuring that your system allows you to target alerts to specific geographic areas potentially as small as the neighborhood level.  You will also almost certainly want to design the system to allow your citizens to opt-in to receiving specific types of information. A resident may wish to receive notifications about severe weather and school closings but not about road conditions. Designing your system in this manner helps ensure that your content will be relevant to those receiving it.

A Holistic Approach
Since very few vendors offer a single product that does everything well, a comprehensive public warning program may require the use of multiple products potentially from multiple vendors. For example, desiring a very robust and redundant EAS program, a jurisdiction may select a product such as EMnet that performs that function very well and also procure a product that specializes in delivering notification by email, SMS, and other electronic means. They may utilize the output of one of these systems to update their website and publish their message to social media. Such an operational concept can be achieved, through effective system integration, in a single operation performed by the user and will be the topic of our final post in this series.

Yesterday we took a very broad look at things to consider when selecting an emergency notification system for an organization.  Today I would like to focus on specific things that should be considered if your system will emphasize providing notifications internally within your organization and to your response partners. There are several reasons that we may want and/or need a system to do such:

  • Provide Situational Awareness of emerging or ongoing events in order to maintain a Common Operating Picture and ensure response readiness as a situation escalates.
  • Inform staff of operational closings and/or the need to report to an alternate work site as part of a Continuity of Operations Plan.
  • Request staff and response partners to respond to an EOC, incident site, or staging location.

Capturing Response Data
One of the first things what we must consider with this type of system is the ability that it has to capture information from the message recipient.  In each of these notification examples we likely wish to have the ability to confirm that the message was actually received by the recipient as well as potentially additional information regarding their ability to respond.  The key here is that we will want to leverage the technology to capture this information on our behalf either through eliciting a text based response to the the message or through the utilization of a touch tone response to a phone call.

The system should be flexible enough to allow the individual initiating the message to create a layer of responses. For example, a message notifying staff and response partners that an EOC is activating may with to elicit if the individual is available for duty as well as determining their Estimated Time of Arrival to the EOC. Capturing this data electronically should allow the individual responsible for making the notification to know if they will have any staffing shortages as well as how long they can expect it to take for the EOC to be fully operational.

Recognizing Positions
If your system will be utilized to activate an EOC or specialty response team, it can be very useful for the system to recognize individuals as filling positions. That is to say that perhaps your jurisdiction’s HAZMAT team has three medical specialists but only one is needed for an emergency. If your system recognizes positions, it can provide an activation message requesting the primary medical specialist to respond and a message to your “backup” medical specialists that the team is being deployed however their response is not required. In the event that the system was unable to confirm that the “primary” medical specialist was available to respond it would automatically request that the next qualified individual to fill that position make their response. Use of positions in this was can greatly reduce the amount of human intervention required to activate resources.

Notification Mediums
Any notification system must be capable of utilizing the maximum number of distribution mediums possible. At a MINIMUM a system procured for internal and partner notification should include the following distribution methods:

  • Email
  • SMS (Text Messaging)
  • Voice (Telephone)

There are a few questions to ask a vendor when evaluating their notification products for these basic notification channels. Distribution of mass messages to email servers and cell phone provider’s SMS gateways routinely causes these providers to identify emergency notification messages as spam and either block or throttle the dissemination of messages. It is critical that the vendor have a working relationship with key email providers and gateways to ensure that their servers remain on “white lists” that identify notification messages as not being spam. The same is true of SMS (Text) messages however arguably even more critical. The vendor must maintain close partnerships with cellular providers to ensure that their messages are not blocked or throttled by the SMS gateway that receives the message to pass it to the cellular towers for delivery. Ideally, the vendor will have dedicated delivery paths to cellular providers that bypass standard SMS gateways and provide priority routing for emergency messages.

In addition to the basic delivery methods of email, SMS, and voice a jurisdiction should consider soliciting the following options for message delivery:

  • Desktop (Computer pop-up) notifications
  • Pager (SNPP) delivery
  • Blackberry PIN delivery
  • Fax delivery
  • LED Sign Board triggering
  • Public Address System activation

Although each of these additional options have a specific role that they fill, one or all of them may be appropriate for many jurisdictions. A notification system that will be used to notify an office building of the need to evacuate and/or initiate a Continuity of Operations Plan could highly benefit from desktop notifications as well as LED sign board and public address system activation.  A hospital that still utilizes alpha-numeric pagers for its staff would certainly want to ensure that their system provides direct access to the paging vendor’s SNPP gateway. Finally, although ofter overlooked in our digital age, a notification system used to alert various other offices may benefit from the ability to deliver a message by fax.

Location & Discipline
If a system will be utilized to provide situational awareness of events, particularly if the audience is large, a significant emphasis should be placed on the ability of the system to target alerts based on geographic preference as well as the type of event or discipline of the recipient. Imagine the amount of information pushed by a system used to provide situational awareness for an entire state. An official responsible for one end of the state almost certainly has little interest in minor events unfolding at the opposite end of the state. The same is true in that a fire chief likely has little interest in a relatively minor public works issue. Ideally in this situation your system will permit recipients to select what information is relevant to them both on a geographic basis as well as the type of event.

Message Creation
If your system includes a telephone notification component, you will want to examine the method that is utilized to create the voice message.  While some jurisdictions are comfortable with the text-to-speech capability that some systems offer, others may find that they either experience pronunciation problems or that their audience quickly disconnects from the automated message with the assumption that it is associated with telemarketing or collections activities. Most systems provide the ability to record your own voice message during activation. This can be achieved either through dialing a special telephone number for the vendor and the system recording your message via telephone, recording your message through a computer and uploading it to the system, or through a direct recording interface within the notification platforms activation screen. If sound quality and activation time are critical to your notification program it is highly advantageous to be able to record your message directly into the application. With that said, the ability to also be able to record a message via telephone provides greater flexibility to activate the system from virtually any location.

Although we will explore the issue of interoperability more fully when we discuss system integration, it is important to note that any system used for internal and stakeholder notification must support interoperability with other systems. This will allow officials that receive notifications from your system to also be alerted to situations that are highly relevant to them but issued via the notification system of a neighboring jurisdiction, another department within the jurisdiction, or aggregated from a partner such as the National Weather Service. There are a few ways to achieve this functionality. A vendor may either provide their own internal support for interoperability as is the case with Cooper Notification’s Roam Secure Alert Network RSIX platform and/or through integration with the federal IPAWS aggrigator program.

The very nature of an emergency notification system requires it to be survivable.  As a result it is critical that the system that we implement must be deployed to ensure the highest level of redundancy possible. If our system is managed in-house (the hardware is physically under the control of your own staff) we should seek a contract with the vendor to provide a back-up server that is synchronized in real-time with our primary in-house server but located off-site and under the control of the vendor. Likewise, if we select an option that is entirely hosted by the vendor, we should ensure that we receive specific information regarding the level of redundancy and diversity of their data centers. We should ensure that the data-centers utilized by the vendor are as robust and hardened as possible and that any redundant servers provided are housed at a separate data-center from the primary server. Ideally, if the primary hosted data-center is located on the East Coast the back-up data-center would be hosted on the West Coast.

In our next post in this series we will examine considerations for system used to warn the public.
Part 3

Many organizations either have or are considering investing in emergency notification systems.  Anyone that has researched available vendors and products in this arena knows that the options available with these systems varies widely.  What is shocking however is that many invest in such systems without having a clear understanding of what they are purchasing or even what it is that they really need.  As such, let’s take a moment to consider what we should look for in such a system.

When considering an emergency notification system the first question that we must ask ourselves is what our intended audience is.  An organization may utilize such a system to:

  •  Inform its employees and/or partners that an emergency exists
  • Provide situational awareness of an emergency situation to leadership and external stakeholders 
  • Request that employees and stakeholders take a specific action such as reporting to an Emergency Operations Center or alternate working location
  • Provide situational awareness to the public of an emergency situation
  • Notify the public of life threatening emergency that requires immediate protective actions.

Identifying what our intended audience and goal is will help us determine what feature sets we should solicit as part of our procurement process.  Some of these features will include the ability to confirm a recipient has received the message and/or has the ability to comply with a requested action, what methods such as telephone / email / text message / fax are available to distributing the message, what criteria such as event type or geographic area may be used to determine recipients of the message, how the database of recipients is maintained, options for interoperability with neighboring alert systems, the ability to integrate with other alert system platforms, and the ability to both activate and be triggered by the Emergency Alert System.

It is important to remember that we need our staff to be intimately familiar with a system that they will utilize during the most severe crisis and as such, if at all possible, we should select a system that will fill our needs during not only such a major crisis but also during day to day operations. This requires both technical planning in the procurement processes as well as operational planning considerations of how we do business.

In follow-up articles we will examine important feature sets to consider for systems to communicate internally within our organization, systems to communicate externally with the public, and finally considerations for integrating multiple notification systems into a comprehensive warning program that may include the Emergency Alert System and Social Media components.

Continue Reading: Part 2