Emergency Management User Model Definition
The user model helps us to define
1)'who is the user' of what we are providing
2) what is the user requirement/behaviour for EM information
Perspectives An emergency service can be viewed from different perspectives. The supplier perspective, who pushes the service, the recipient perspective, who 'pulls' it, and possibly something in between.
Typically, we have identified a few broad 'groups of users'
1) People affected by the emergency status: located or missing Emergency need: primary (in need of urgent assistance such as medical, food, water) or secondary (long term assistance with recovery). INFORMATION REQUIREMENT Need to make their status known to the suppliers of service, or other agency, need to inform friends and family of their location and status
2) Family and relatives (local or remote) status: may be looking for other friends, family or relatives Emergency need: primary, secondary or only need to locate people affected by the emergency INFORMATION REQUIREMENT communicate with field workers, with affectedPerson
3) Emergency field workers and volunteers (local, remote) While deployed, they have access and can collect situation data/information in real time, and need guidelines/tools on what to do with this data so that it is used to update the information chain in real time, to obtain accurate situation status May have to comply with operational model of organisation they belong to, or in the absence of an operational model will benefit from standard guidelines. INFORMATION REQUIREMENT Need to communicate with orgs, field workers (and affectedPeople?) In addition to practical assistance roles (medical, counselling, housing, social, other specialised etc) field workers also compile/maintain lists of affectedPeople and their status Typically this information would have name/gender/dob(age)/location - then they have to decide what to do with it. Information sensitivity should be taken into account (dead-alive-injured was best not broadcasted) however other attributes such as 'related to' /hotel where they checked in/ is considered ok to share. As different field workers may follow different guidelines/information models, for the information to be aggregated on the web without exceeding customisation overheads, it is necessary to have some common schema that can be be adopted by all and is considered one of the desirable outcomes of the EIIF Incubator. Field workers allocated to information gathering/dissemination have access to standard IT tools and infrastructure, and are generally literate
4) Emergency agencies and organizations (remote and local), They tend to have internal procedures and specialised capacity, Their role is to provide 'emergency service' as per their mandate , main task is to ensure efficient supply of service They need to locate/admin/monitor the situation of emergency as it changes, They need uptodate information as it becomes available
INFORMATION REQUIREMENT Challenges: In addition to the usual challenges such as language and logistic constraints
1) internal coordination of information and resources
2) external coordination of information and resources with other agencies (rationalisation and prioritisation of supply)
3) coordination with local governaments and agencies (local policies)
This is likely to need a highly dynamic information exchange capability Have access to resources, IT infrastructure, skills OK
5) Other (government agencies, media etc) International media organisations generally look for stories, they have little interest in privacy and sensitivity of information However, especially through their websites, can provide strategic information dissemination service, they need some kind of social contract to engage them (agreement with the information suppliers that the emergency information is treated for operational purposes for the benefit of the affected people, and not to make the news), and a data exchange format/schema that they can work with
This segmentation points to different information needs and priorities, understanding such information requirements, will help us 'guide' our information model. Note 'information' here is intended as a functional elements of operations, necessary to support efficient supply and management, and not in the media sense.
Test cases can be derived from/matched to user models