Incident Command and Information Flows in a Large-Scale Emergency Operation

This week I am bringing you a paper that is very directly relevant to you if you are currently designing were trying to improve how your organization does incident response, or if you’re a responder yourself.

It does a good job of highlighting that though you see “incident response system” or “incident command system” a lot, I help teams develop frameworks. They’re a floor from which they can stand on and build on, not something intended to limit them.

Incident Command and Information Flows in a Large-Scale Emergency Operation

This is a paper by Rune Rimstad, Ove Njå, Eivind L. Rake, and Geir Sverre Braut in which they discuss how information flowed and how that contrasts with the official plan in Norwegian incident response. That might seem strange at first, but the Norwegian system is fairly similar to the one in the United States, the incident command system (ICS). Additionally, looking at how other countries and teams do things can offer us a different perspective to help us evaluate our own approaches and learn new things.

The authors focus on a terror attack that occurred in Norway in 2011, specifically on one area, Elstangen, a hub where multiple agencies had to work together to treat survivors.

To start off with, the authors looked for other research on information flow during this incident. Interestingly, they couldn’t really find much information. What’s especially strange about this is that there was a lot written about administrative information flow and flow at higher organizational levels, but almost nothing about information flow among responders on the ground.

Patterns of information flow

There are four main patterns or network topologies that the information networks can resemble in crisis response situations. In each, the amount of information that flows through the network, in which direction, and the role of a central response organization changes.

This is a model that can be used to think about what the central response organization is at your company. Some companies I’ve worked with end up having their own incident management organization; In others, this is the function of SRE.

Once you’ve identified which area acts as the central part of the network, you can then determine which of the patterns communications most resembles. Is that how you want information to flow? I’d venture that the topology that the org resembles today doesn’t necessarily match the way you want communications.

For software companies, this can be a sign that some sort of incident response framework is missing or that the current one doesn’t work for the organizations goals.

(Want help implementing an incident response framework in your organization? You can email me, I’ve helped lots of teams with this)

The response

Part of the attack included a shooting at a youth camp on island, Utøya nearby. This meant that that rescue and triage would need to take place between the island and the mainland. This is where Elstangen comes into play.

But first, the response had to be organized. In the Norwegian model there is an incident commander, a fire commander, and an ambulance commander. The policy as written states that the incident commander is assigned, but in this case, one was chosen at the response level and then approved. A police officer, originally set to be a responding officer to the island saw that there wasn’t an incident command and had previous incident management experience, so he became the incident commander.

He asked an anesthesiologist who wasn’t local to be the medical commander (different from the ambulance commander and typically a physician in their system). They weren’t local, but the anesthesiologist had previously taught some of the classes the ambulance crews needed so he knew the crew. The fire commander was chosen in advance, as is normal practice for them.

A golf course was chosen for the staging area since it had space and could have helicopters landed, but upon arrival some of the ambulance crews realized that the narrow bridge it took to get to it would create a bottleneck and moved it to a nearby field that had space and was more accessible. This however, meant that some of the commanders had to relocate. They were then able to set up a command center, where they primarily remained.

When interviewed, many of the responders and commanders said that they ended up spending most of their time on their specific area tasks. That is medical for medical and rescue for rescue and such. This is interesting since, as the authors point out, there are debates and discussions about whether a command and control or coordination model is appropriate on-scene.

Ultimately rescue efforts would last from about 19:00-22:00 with continued search for victims throughout the night.

Information flow in the incident

Once the commanders had gotten together and were able to get this station setup, they felt the outlying operation centers that were previously facilitating communication became much less important for doing so.

Though the official communication and coordination structures and channels were now set, it turns out that much of the information came from informal (“weak ties” in information network parlance) connections and communications. For example, the medical commander, while not otherwise busy, was able to place a call to some other doctors on the island. They were able to provide information that set priorities on the island.

In addition to local knowledge helping coordination, all responders interviewed expressed some version of the idea that it also helped to drive creative solutions to problems, such as calling other physicians. Or one helicopter pilot who knew some of the police officers and was able to listen to their discussions and radio traffic to keep informed.

Communications in general were hampered by radio troubles, both with poor coverage and some incompatible networks. Cell phones were used as well, but also suffered from some reception issues.

Much of the official communication took place first, face to face among commanders, with short (less than 5 minute) briefings happening ever 20-30 minutes. This means that almost all communication from the command center was “highly processed” by those present before being available to others.

Looking at the possible patterns, this is closest the “forest” type where silos end up being created with various teams and sub-organizatons working on their own. Normally, or at least, on paper according to written procedure, one would expect to see a “pyramid” flow, where information flows top-down.

Commanders were actively searching for relevant information throughout the incident. This in combination with the forest model, created an interesting situation where anytime a commander communicated new information to others at a briefing it gave others the idea that the given commander had a better overview of the situation than others.

This further created the impression expressed by responders in interviews of a lack of information being available. Most of the content of the briefings were characterized as mundane by responders and not really important. Whereas things like the safety of personnel, number of patients, and how many (if any) were in the water were deemed essential.

Ultimately the structure differed from the “official” model in two main ways, the different number of commanders and the fact that they weren’t chosen by a higher authority, and instead chosen by those at the sharp end, often in consultation with their colleagues.

“There seem to have been a collective understanding among front-line personnel of the need for, and appropriateness of, establishing an incident command structure in accordance with the official system, but on each spatially limited scene”

Those at the sharp end interpreted the Norwegian system to be a flexible one, at least in this point, and divided up the large areas between the island and mainland as they felt was appropriate.

This highlights an important feature of incident response frameworks. One of the first things I tell teams or organizations I’m working with, is that the most important feature of a framework is that it exist. This might seem obvious, but a number of teams, large and small operate without one. Without a framework, it can be difficult to communicate ideas around where it is flexible or rigid. This forces every responder to have to evaluate these things for themselves, each time anew.

Internal communication around incident procedure, especially after an incident can shape this as well. Pushes to further standardize or admonishments to not do some adaptation (multiple slack channels for example), reinforces the idea that the framework is rigid, which causes some of the benefit to be lost.

Takeaways

• Incident response systems are often designed with flexibility in mind, but efforts to standardize and codify can erode that flexibility. This causes the response system to lose some of the benefits.
• One way to think of various incident response methods is as either command and control or as coordination.
• In rapidly changing incidents, a strict command and control model will fall behind if it seeks to remove the ability of responders to adapt.
• Important information can be communicated through “weak ties,” those parts of the information networks that are not part of the formal process. Attempting to restrict this can cause a loss of information flow.
• Commanders were chosen based on their knowledge of the area and had worked with at least some of the other crew before.
• Examining how other teams and even countries structure their incident response can help highlight areas of improvement in yours and also highlight successful practices.
• The most important aspect of a response framework is that it exists. Without that, larger ideas around flexibility or rigidity or permitted responses cannot be communicated and must be decided individually in the moment, each time.