Reminder: Please remember to sign any post you make by clicking the signature button (the last in the row at the top of this window).

Comments

Synopsis

Here is a brief synopsis of the current comments from the Sahana Discuss mailing list:

On 12/3 Glenn introduced the topic:

In our small-scale drills, we've just been defining a top level "disaster".  The distinction between "incident" and "event" is vague, other than being at different 
levels in the   hierarchy.  Would just a 2-level hierarchy be enough (and less confusing)?  Has anyone in an actual PHP deployment used all 3 levels, and found that 
helpful?  How about Eden?

BTW, we're distinguishing disaster trees as either "test" or "actual".

Thanks for any insight.
- Glenn

Fran Replied

Eden doesn't do this - we have location-based deployments, but not
incident-based.

> BTW, we're distinguishing disaster trees as either "test" or "actual".

This is far more useful & something we want to have as a deployment
setting to clearly brand as such...

F

Glenn's Reply to Fran

Fran,

Are you adding locational data to an incident or are you adding locational data to everything else in the system? In the latter case, how do you distinguish 
when two geographically relative entities (persons) are the result of different disasters?

-Greg

Fran

I'm not sure how 2 things with the same name in the same place are
different in any way just because they were recorded in the system as
a result of different disasters?
A thing is a thing & we see the solution as being for the lifetime of
mitigation, preparedness, response & recovery - not just response.

F

Darlene's reply to Glenn's original question:

Hi Glenn & all, 

Good question and I'm glad you brought it up.  For Mayon development so far we've avoided using 'disaster' purely for political reasons; not everything Sahana 
could be used for is a 'disaster', so we've gone with 'event' for the large scale deployment.  We see an 'incident' as a sub-level of 'event' (though not in 
scope for the CUNY SPS team's work).   

For example: 
There's an earthquake (event) and a fire breaks out as a result (incident). 

We chose incident to mean that so it would mesh with the nomenclature of pro incident management tools like E-Team, who use that definition of incident.  We don't 
see Mayon as it is now handling that kind of granularity, but hope a plugin could be developed to work with E-Team on the ground someday. 

Hope that helps.  Looking forward to other's comments and thoughts. 
-Darlene 

Mark's reply to Darlene:

aaargh.

Darlene-- Sorry I need to correct your terminology.

In the emergency management field - an incident is "unplanned" and an event is "planned"... so it is much more appropriate to consider them at the same level.
In fact, a natural disaster under ICS and NIMS is defined as an incident.   [[Incident_command_system#Basis]]

I'm sure Gavin might have much more to say here.

Mark

Don enters conversation

Mark, all - This terminology is not unilaterally applied. Throughout much of the world an event is a series of interconnected incidents – e.g. the SE Asian Tsunami 
was an event comprising of many incidents across several countries. The recent major bushfires in Australia (and currently across Israel) are an event of many 
individual incidents. Most major catastrophic events are unplanned and categorised as a series of interconnected incidents. 

Catastrophic event management is generally regarded as the hierarchical approach to incident management – disparate incidents are all managed under a single umbrella 
(eg ICS, NIIMS etc.). “A disaster is a natural or man-made event that negatively affects life, property, livelihood or industry often resulting in permanent changes 
to human societies, ecosystems and environment.” (ICS Instructors Guide).

Don

Chamindra

With regard to how we used that hierarchy in Sahana phase 2. We implemented it in keeping with the emergency management conventions that was mentioned by Don (actually 
I believe Don was the person who asked us to design it this was as I remember). However unfortunately most of the modules did not implement that hierarchy and data 
separation in their modules so it became quite redundant.

From what I have learned on data separation by incident, it is valuable if Sahana is going to be used for emergency management as there might be multiple 
disasters/emergencies coordinated in parallel. What you are creating is  spaces for responders to different incidents to collaborate and eliminate the noise of the other 
events. You could say we could just host another instance of Sahana or implement multi-tenancy in Sahana, however there is a lot of common data that is still valuable 
between events.

As some data is valuable to be share and some to be separated by incident (sometime it differs by application as well) the Sahana platform architecture needs to support 
it from ground up IMO.

Chamindra de Silva

Mark

aaargh - you are right - wrong again! (wrong am I, I mean) ;P

I was thinking of a planned event - such as an ice or water distribution (the event) in a neighborhood because of a power disruption (the incident) - something NYC 
does every summer.... but you are absolutely correct about the "event" in the sense of "catastrophic event management"....

Not enough sleep this week.... thanks Don for the course correction.

Best regards,
Mark

Mark

Agreed.  Great to have this discussion on a large and open list of interested Sahana people.

This also recalls the discussions we had in Monterey last year about setting up a global directory server where Sahana instances would register their location and what 
disaster/incident/event they were tracking data on... an idea we brought forward to discuss at Pulse Camp last week.  Chad and I were discussing simultaneous event 
management today at RHOK and the needs of sharing data between the coordinators or responders of different events.   I think overall we need to retain an internal way 
of tagging the (event/disaster/scenario/incident/?????) that a Sahana instance is tracking data on.... I'll be writing a little something on this and maybe we can all 
flesh it out on our ideas: wiki.  Organizations looking to implement Sahana for long-term preparedness and potential use for multiple events, like NYC should help drive 
these requirements rather than simply speculating.  Chad - do you want to share your thoughts on how your team has thought about this.

Best regards,
Mark

Don Reply to Mark

Hi Mark,

It was really just a matter of timing J ... Your email popped in to my Blackberry as we were flying over the flooded areas of my home town assessing damage and road 
closures (our town and several others in regional NSW have been isolated for several days; others are in the process of large-scale evacuations - 
http://news.ninemsn.com.au/article.aspx?id=8175881 ). 
 
Last Wednesday a severe weather event caused wide-spread flooding across our State. We are currently running in excess of 800 reported incidents associated with the 
event requiring of a response. Most are flood-related (homes and businesses inundated with water), however this type of event also leads to traffic accidents, isolation 
events (people trapped requiring of medical assistance), damage to homes from falling trees etc.  

As always during large-scale disaster response it’s important to be able to centrally track and manage the logistics of responding units and personnel to all the individual 
incidents as well as details of those impacted by disparate incidents in a central management system – otherwise we could never coordinate all the requirements within the 
context of a finite resource-base (some of our State Emergency Service flood response units are driving in excess of 300km just to get to impacted remote towns and villages).

... and it just started raining again L

Cheers, Don

Micheal Howden

Hey,
Just a few thoughts:
I’m sure that this is a bit simplified, but:
Disaster = Hazard x Vulnerability. An Earthquake is an Hazard, vulnerability (such as people living on a fault line and poor building standards) can create a disaster. 
As Darlene said the word “Disaster“ is very political in many contexts, and often to use it means someone has to admit that the situation is beyond their capacity for 
dealing with it, with the people in charge are often loathed to say! Perhaps “Hazard” would be a better term, but couldn’t this just be a category of incident? 
(It is already in Eden)
I would personally try to avoid the term disaster all together.

And then we can get at looking at the impact of the hazard, which is currently done in the Assessment Application. We need to think more about how we 
integrate/verify/consolidate assessments from various sources (with different levels of trust) and over time (10 people trapped, no 20, no 30, no 7…. Oh, they’ve already 
been rescued).

Regarding databases of disasters, do people know about: http://www.desinventar.net/ (I don’t know much more other than the fact it exists). 

Oh, and Glen’s comment about distinguishing between test (or demo) and actual “disasters” - +100 We really need to get onto this in Eden – I deployment setting me thinks.

Cheers
Michael

Glenn's Response to Michael

Sometimes, saying "disaster" is helpful.  In the US context, a "disaster" (if formally declared in a prescribed way) can mean that HIPAA privacy rules are waived, which 
can allow wider information dissemination (without being sued/jailed).

BTW, we had been differentiating 3 categories: test or demo, drill, and real event (not a drill), but are heading towards combining test/demo/drill into 1 category, "test"
- Glenn

Gavin's (really long) reply

Warning! Warning! One of Gav's long emails. Look away now! ;)

On 2010-12-04, at 07:51 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote:
> In our small-scale drills, we've just been defining a top level "disaster".  The distinction between "incident" and "event" is vague, other than being at different levels in the hierarchy.  Would just a 2-level hierarchy be enough (and less confusing)?  Has anyone in an actual PHP deployment used all 3 levels, and found that helpful?

I'm not sure how many years we'd have to go back to find the previous discussion on the hierarchy, but years ago I made the suggestion, and it stands today that it shouldn't be a fixed hierarchy. It should start with a single entry at the top level, and basically provide a completely flexible structure that allows the ability to add a new child to existing entries, or create a new top level entry. We also need to be able to archive, and move (e.g. a child from one parent to another).

-1 to a fixed hierarchy.
-1 to fixed terms for different levels in the hierarchy, just let the users use the name they want. 


> BTW, we're distinguishing disaster trees as either "test" or "actual".

That's a nice improvement - just as long as the text can be edited, most emergency managers would probably call actual "event" or "incident" and tests "exercise" or possibly "simulation". One suggestion I made way back was when viewing in the context of an "exercise" that the banner up the top should display a clear "EXERCISE ONLY" header bar and the top (and probably the bottom of each page delivered.

As mentioned above, we also need the ability to flag as archived.


On 2010-12-04, at 08:22 , Fran Boon wrote:
> A thing is a thing & we see the solution as being for the lifetime of
> mitigation, preparedness, response & recovery - not just response.

Agree - however, if we think about this generally, what we are in fact talking about are contexts, or workspaces. A means of providing a high level filter to simplify focusing on the information that a user desires. That is all the event/incident approach has been for in the past - to allow a user to focus on just the information that is relevant to them. 

This of course can just as easily be applied to the 4Rs (Reduction, Readiness, Response, Recovery). E.g. on context in Readiness - there might be a context used for planning an upcoming exercise, or a group that is working on a particular response plan. In Reduction, it may be to focus on a specific risk assessment process. In Response it may to be focus on Building Safety Evaluations, or management of rescue teams/CERTs. In Recovery it may be to  plan and prioritise the reconstruction of infrastructure.

So I don't think its actually incompatible with the broader elements of comprehensive emergency management, and indeed it would support it.



On 2010-12-04, at 09:37 , Mark Prutsalis wrote:
> In the emergency management field - an incident is "unplanned" and an event is "planned"... so it is much more appropriate to consider them at the same level.  In fact, a natural disaster under ICS and NIMS is defined as an incident.   http://en.wikipedia.org/wiki/Incident_command_system#Basis

Perhaps the difference between the US context (and that wikilink) is that event is used as shorthand for Event Management (something I had a bit of exposure to in Washington DC with DCEMA as an intern, as DCEMA also led the DC Govt event management as well as emergency management). But that is a fairly rare case as a lot of emergency management agencies don't directly get involved in event management (even thought they should) and it is often left to police/fire/ambulance instead - which it is here in NZ for example.

However, event is often used to describe unplanned events, e.g. the recent Canterbury 7.1 Earthquake is an 'event' even though it is unplanned. Again, the semantic different between event (very general and can be applied to anything) and event (used in the context of organised and managed events) is subtle - but they are both valid.

Arguably, a given jurisdiction could have multiple 'managed events' occurring simultaneously, so from a management perspective, these would likely be treated as separate stand alone 'incidents' :)

> I'm sure Gavin might have much more to say here.

Good guess Mark - just got back and catching up ;)

So, given that these terms are so loaded, I still come back to the suggestion that we go for as generic a solution as possible, a flexible tree hierarchy and we let users name things whatever they want (although being able to flag 'exercise' or 'real' is definitely required), and structure them conceptually in a hierarchy that suits them best.



On 2010-12-04, at 18:02 , Chamindra de Silva wrote:
> With regard to how we used that hierarchy in Sahana phase 2. We implemented it... However unfortunately most of the modules did not implement that hierarchy and data separation in their modules so it became quite redundant.

Yep - that is exactly why the implementation in current Agasti has failed. It needs to be a core capability, and every module needs to be context/workspace aware.

> From what I have learned on data separation by incident, it is valuable if Sahana is going to be used for emergency management as there might be multiple disasters/emergencies coordinated in parallel. What you are creating is  spaces for responders to different incidents to collaborate and eliminate the noise of the other events. ... there is a lot of common data that is still valuable between events... As some data is valuable to be share and some to be separated by incident

Yep. This is exactly the reason we don't want separate standalone instances replicating people and organisations, let alone a lot of the core mapping data (just an example). Not to mention that users may start in one context, and as things change they may move to another context, so from a user account management perspective, much easier to have a single deployment.

Of course this is only really important for ongoing deployments of Sahana products, and isn't needed for one-off deployments (which appear to be our current expertise ;)

I, and I imagine Don, would probably argue that not having an implementation of contexts/workspaces is holding back deployment of Sahana within more developed EM organisations that will deploy Sahana _before_ an event.


On 2010-12-05, at 12:28 , Mark Prutsalis wrote:
> This also recalls the discussions we had in Monterey last year about setting up a global directory server where Sahana instances would register their location and what disaster/incident/event they were tracking data on...  and the needs of sharing data between the coordinators or responders of different events.   I think overall we need to retain an internal way of tagging the (event/disaster/scenario/incident/?????) that a Sahana instance is tracking data on.... Organizations looking to implement Sahana for long-term preparedness and potential use for multiple events, like NYC should help drive these requirements rather than simply speculating.

Definitely. However, the natural home for some of this would probably be with OASIS EDXL - e.g. the SitRep extensions that is currently in development would need the taxonomy of events/incidents available to know how to assign a given SitRep to an incident. And given that we're working with other systems, including commercial systems, we need a platform neutral, standards-based implementation to achieve this. Certainly something we should develop and prototype with a testbed in Sahana, but in the long term I think a fair amount of it will need to be standards-based and integrated with EDXL.

I really need to dive into EDXL to see what already exists in this context, as well as some of the work in draft and see what the gaps are to make this work.


On 2010-12-05, at 22:54 , Michael Howden wrote:
> I’m sure that this is a bit simplified, but: Disaster = Hazard x Vulnerability.

Close, that is actually a very commonly used definition of Risk = Hazard x Vulnerability (and sometimes x Exposure as well). This definition is actually laid out in a number of formal standards - primarily Australia/New Zealand Standard 4360:2004 (now 2009), which has more recently become the ISO standard on Risk Management (ISO 31000:2009). It is still a simplified concept - however the important point is that when looking at hazards and vulnerabilities, you are primarily performing this assessment before an event. In the emergency management context, this primarily occurs during the mitigation/risk reduction element.

On 2010-12-07, at 05:54 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote:
> Sometimes, saying "disaster" is helpful.  In the US context, a "disaster" (if formally declared in a prescribed way) can mean that HIPAA privacy rules are waived, which can allow wider information dissemination (without being sued/jailed).

Agreed - we have to allow the ability for countries and jurisdictions to tweak terminology to suit legal requirements. And there may even be multiple declarations made that have to be recognised. E.g. in the US, declarations of disasters may occur at multiple levels, as they open up funding and other powers (e.g. a Federally Disaster Declarations). It also depends on what section you work in, in health, there are different declarations that make  special health powers available during say a pandemic.

Two key points from this:
1. We need to think about how we include declarations, and we recognise that the terminology and how they are used varies from country-to-country, as well as sector-to-sector.
2. At the same time, a lot of declarations don't occur straight away, and in the case of slow-onset events like floods, they can occur days, or in the case of droughts even weeks or months after the initial 'incident'.

However, declarations may be different from an operational hierarchy, and it may just be that when adding a declaration (and there may be multiple), that the user is presented with a list of all open entities in the hierarchy, and they click which ones are covered by the declaration. A national one may cover them all, whilst a local jurisdiction declaration that was probably declared before the national one would only cover a smaller subset.

Just some fuel for further discussion ;)

Cheers Gav

Chad

Gavin,

I completely agree with this on a theoretical level, but practically, implementation is extremely daunting because workflow is tied so closely with 
the hierarchical level. To make it modular we'd need a workflow management framework which quite expensive to implement. I welcome the challenge but 
can definitivley state that, at least as far as our Mayon contribs are concerned, it's out of our reach. 

Regards,
Chad Heuschober

Chamindra

This is exactly the limitation we faced with Sahana phase 2. If you note the disaster hierarchy and terminology was configurable, however implementing 
that level of data separation and reporting proved to require quite a significant amount of effort, which non of the module writers had time to implement. 
If this is going to be done it has to be done at a core Sahana framework level and supported by the Sahana API. To build in that level of flexibility 
you need to consider building in a more generic workflow/rules engine based system which is a lot more effort.

Chamindra de Silva

Gavin

On 2010-12-07, at 14:59 , Chad.Heuschober@mail.cuny.edu wrote:
> I completely agree with this on a theoretical level, but practically, implementation is extremely daunting because workflow is tied so closely with the hierarchical level. To make it modular we'd need a workflow management framework which quite expensive to implement. I welcome the challenge but can definitivley state that, at least as far as our Mayon contribs are concerned, it's out of our reach.

I don't think I ever said it would be easy... ;)

On 2010-12-07, at 17:50 , Chamindra de Silva wrote:
> If this is going to be done it has to be done at a core Sahana framework level and supported by the Sahana API. To build in that level of flexibility you need to consider building in a more generic workflow/rules engine based system which is a lot more effort.

Agree, and it also links into Security/ACL as well. Definitely agree with Chamindra that it is a core API issue, and would need integration with workflow, messaging and security.


The alternative is perhaps to forget about including a tree for events/incidents, and just allow the tagging of all entries in the database with taxonomy terms (quite possible a controlled taxonomy, and possibly multiple controlled taxonomies). I personally prefer simpler and more flexible solutions, and if we can do this another simpler way, then we should. Operating in a given context would then result in nothing more than a simple db filter to limit display of query results to those filtered by the current taxonomy term.

This would of course allow other contexts to be used - not only event/incident, but your could break things out by planning, intelligence, operations, logistics; ESFs for the US folk, or even specific organisations by name.

I'm not sure this would need to be tightly integrated into workflow, it is nothing more than a filter to only display entities with certain terms attached to them.

This is also clearly not a hard solution, as it is something that Drupal has done since v5, so the concept should be able to be easily pinched from there.

I'd probably prefer this simpler, generic, and more free-form tagging approach rather than hard coded functionality.

Cheers Gav

Fran

Ah, now we're talking :)
Eden already supports flexible tags in the underlying Data Model.

The one resources that I've thought of so far which really require
this per-Incident filter would be the DVR & Building Assessments.
I'm happy to hear other specific use cases...

F

Don's Extra Long Post:

Hi all, 

At risk of replicating Gav's fear of another long post :-)

Much of what we are discussing was covered during our initial presentations
at the 2005 Sahana workshop with the team in Sri Lanka (I recall presenting
and white-boarding the escalation and decline of an Event/Incident
hierarchy) and as Gav notes, followed-up by later presentations including
the procedural flow-charts from EMS that I forwarded (from memory) to the
e-lists around the same time.

However, and probably unfortunately on the part of the domain team of the
time, I don't think we ever managed to properly 'sell' the concept to
developers that Emergency Management is not something distinct and separate
from Humanitarian or Disaster response; rather EM is simply the
formalisation of a set of lessons and procedures learned over many
generations, and tens-of-thousands of responses, as to the best way to
manage any disaster; man-made, natural, humanitarian or environmental. The
protocols are eminently scalable upwards and downwards; they can be very
complex; they can be as simple as ensuring that basic records are kept and
that *someone* is in charge. They can be exercised by highly trained rescue
teams; they can be understood and followed by the absolute novice helping
remove rubble from a trapped victim. 

Many countries maintain and exercise highly advanced disaster (emergency)
management protocols - many others are yet to implement even the most basic
of protocols - the only real difference is geography. Over the past 5 years
a great many countries have adopted ICS and/or NIIMS or equivalents.
Instructors are working overtime travelling the world to help countries in
need. 

Yet from the outset Sahana was viewed as somewhat different and distinct to
all of this in that in grew from an adhoc and very chaotic response to the
SE Asian Tsunami. Sahana did a fantastic job and I recall a number of
discussions where Sahana was touted more as a crowd-sourcing tool for
spontaneous responders than as something fitting within and providing
assistance to recognised disaster management frameworks.

The only problem with this approach - as history now teaches - is that for
the most part disasters are not as complex as the SE Asian Tsunami and
spontaneous responders do not use or want formalised management tools. They
just want to get the job done and go home. In the context of disasters;
formalisation is inherently part of organisation, in turn part of
coordination and control. Management systems work best when management
supports, implements and understands the management system in use.   

My home community is currently in the grip of a minor flood disaster so in
hope of adding some context to all of this - the current flooding in NSW is
a medium-level natural disaster (as such probably not newsworthy outside
Australia), of the following proportions:

Disaster Events: 1x severe weather event (another projected for tomorrow and
Friday)
Emergency Declarations: 6 x Regional districts
Area impacted: > 100,000 sq km
Persons impacted: Approx 2 million
Persons evacuated to date: > 3,500
Responded incidents (RFA's) to date: > 1,370
Incidents closed: 93% 
Calls for Assistance: 5,566
Estimated monetary losses: > A$1 billion
Responding Orgs: State Emergency Services, Fire Brigades, Australian Army,
Australian Air Force, VRA, Local Govt, various NGO's and local citizens.

It would not be possible to use Sahana for this disaster in its current form
- we simply could not scale to the requirements.. But on the upside, and as
Gav and others have noted, I don't see adding levels of scalability as
particularly onerous - although I do think it requires more than a simple
filter...

Don

Gavin

Well, even for an incoming message log it would be fantastic. As messages are recorded in the system, users could go through 
and note relevant tags against them, e.g. rescue, welfare, infrastructure etc, and this would ensure that these incoming messages 
then come up for display in the relevant sections, without haven't to be displayed for all.

So it definitely doesn't have to be used for just incident management, but also for a broad flagging tool e.g. add a tag that 
represents the 'rescue' section of the responding organisation, and it automatically pops up in their context. 

Same thing can probably be used for task assignments as well, of course this requires using a controlled taxonomy of people and 
organisation entities. E.g. tag a person, or organisation to a task/action/project.

It can be pretty broadly applied across the whole system, and a lot of modules and functionality.

Cheers Gav

Fran

Tagging certainly - we already have that as a core entity :)

It's the per-Event/Incident filtering that I was interested in more
use-cases of.

Other than DVR (inc BA) which are very definitely specific records for
a specific one, the others would mainly seem to be about metrics
after-the-event (for learning/funds-seeking) rather than of
operational use.
Messages, etc could be archived after 1 event to leave the system
clear for the next one or else the filters could simply be set by date
or geographic location.
Even if there were a single system used for 2 separate Events managed
by entirely different teams of people, I would prefer to automatically
route Messages based on Telephone# / Email address received on or
Geography (either automatic or manual) to an Organisation rather than
require manual tagging/filtering....if we were doing manual tagging,
I'd prefer it to still be to responsible Organisation than
'Event/Incident' - even if this is a 1st level triage & the org
routed-to manages the 2nd-level triage...

F

Chad

Perhaps 'm not seeing it, but how is the system supposed to be able to do resource management without workflow definition tools?

When hurricane scenario is defined, the staff pool is created and staff are weighted for response according to the rules defined by the EM, placed into their staffing wave, facilities are identified as shelters and routing centers, and messaging channels are set.

Once that scenario is activated as an event (Hurricane Harry), all of those resources are pulled into the active Hurricane Harry event pool. I agree that it's plausible that HH could cause a fire as a secondary or child event, but how does one treat the resource needs of the fire? Is is pre-defined as an independent scenario somewhere? If so, what happens if its resources are already responding to HH? Are the resources shared? Are they exclusive? Are routing centers shared but not shelters?  When a client registers at a shelter, are they asked which event they're part of?

Questions like these are what make the implementation seem so daunting. Adding to that, most US EM orgs that we've had contact with already have incident management software. Incident information routing, response and containment is generally a different group from those who focus on human services.

I'm generally not one to bring problems without solutions, but we couldn't think of an elegant way to solve these issues. I'd genuinely like to hear your thoughts on this  
 
Regards,
Chad Heuschober
talk/ideas/event_hierarchy.txt · Last modified: 2010/12/18 17:35 (external edit)
Back to top
CC Attribution-Noncommercial-Share Alike 3.0 Unported
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0