Blue Print - Incident Reporting

Allow the people to report Incidents with structured data.

See Sahana First Response (SAFIRE)

Data Model

Incident

• Date
• Location
• Category
• Reporter
• Comments

Components:

• Status (Allocated depending on authorisation)
  • Reporter
  • Status (Verified, Resolved, False... ?)
• Impact (also used in Assessment)
  • Type (see below)
  • Value

Impact Type

• Single field to allow customisable types of impacts to be defined:
  • Number of People Affected
  • Number of People Injured
  • Number of People Deceased
  • Number of Houses Destroyed
  • Number of Houses Damaged
  • Number of Cows Lost
• Restricted to Admin
• Defined in the Situation (Sit) Module
• Also used in Assessment

Workflows

• Incident Reported
  • This could use a hand crafted view which expose a number of different impact types, and then separated these in a incident resouse with multiple impacts in the controller.
• Incident Status Update
  • This could be done through custom buttons on the view using AJAX
• Related Incidents can be linked to each other using BluePrintResourceLinking
• An incident can be used to initiate a assessment, request, task, etc
  • A Status record is automatical created
  • The new resource (assessment, request, task...) is linked (BluePrintResourceLinking)
• Incidents are displayed on maps with icons according to their category.
• Review Incidents
  • This could produce a list of incidents with additional fields with data extracted from the status, such as current status and associated resources

Mobile Client

A Basic, proof of concept, mobile client should be able to collect the following information:

• Date
• Location
• Category
• Reporter
• Comments
• Impact A (TBD)
• Impact A (TBD)
• Impact A (TBD)
• Photo(s)

Legacy Comments

Usability Suggestions

Usability Suggestion for IRS.doc

• All points for this document have been actioned, except:
• "Put a “search” button after the search column" for irs/report. This might not be required as the search will happen automatically on key-press and this will involve going into DataTables API.

Simplified Categories

• #508

Status =

• Complete as of r1143

We need a simplified version of these to be presented to users whilst keeping the full sets available for EM professionals ('Editors' in a simple use case). A mapping needs to be maintained between the different lists. We should have a (personalisable) configuration option to show which list to use (& hence which symbology set to display on the map).

The back-end should NOT be easily customised as otherwise it is hard to share data between instances.

Proposals

Fran

Change to something more like this (doesn't yet handle the mapping - needs work!):

irs_incident_type_opts = Storage (
    INTERNAL_FORMAT_1 ={
        simple: T("Broken Road"),
        canada: "roadway.roadwayClosure"
    },
    INTERNAL_FORMAT_2 = {
        simple: T("Broken Bridge"),
        canada: "roadway.bridgeClosure"
    },
)

A subclass of IS_IN_SET() is created to handle this data structure, providing access to full list to a role (default to 'Editor'), but the sub-set to normal users' dropdowns.

• Q: Should .represent also be modified for Display of records?

nursix

a) keep the original dict, but change the values of the dict into tuples like:

irs_incident_type_opts = {
        101: ("roadway.bridgeClosure", T("Broken Road")),
}

b) make the .represent towards normal users show the second item in the tuple rather than the first (easy tweak), while admin users may see both (the controller can switch between those two)

c) have a admin-only-accessible DB table irs_incident_type_opts with the options available for the "normal" user like:

define_table("irs_incident_type_opts",
             Field("code", "integer", requires=IS_IN_SET(irs_incident_type_opts)))

d) In the model, make .requires the normal IS_IN_SET (To allow Sync of records with any of the options):

.requires = IS_IN_SET(irs_incident_type_opts)

f) In the controller, if "normal" user, override this requires by:

allowed_opts = [opt.code for opt in db().select(db.irs_incident_type_opts.code)]
.requires = IS_IN_SET(allowed_opts)

keith, marr

A config screen for admin/editor to map "simple category" to "canadian category". Assume that total number for simple category options is small and limited, say 6 for Taiwan's case. In IRS report adding screen, default menu using simple category, user can switch via radio-button to canadian category.

Note that if the category code options differ from instance to instance then you cannot exchange the incident reports anymore - therefore I suggested to keep the original options dictionary keys, and just add a second "user-friendly" category title (nursix)

keith

To define "Incident Category" isn't an easy work. The Candian ems.incident seems too detail for a large disaster management system. e.g. It should be "Transport/Railway" instead of "Railway/Hijacking" We might start from small to define our own incident categories to increasing user experience without missing the flexibility and accuracy.

The way to category is using primitive way "number range":

    irs_incident_type_opts = {
        1:T("Natural Disaster"),
        2:T("Transport"),
        3:T("Collapse, Illness, Injury, Trapped"),
        4:T("Industrial"),
    }

    irs_incident_subtype_opts = {
        100:(1, T("Flood")),
        101:(1, T("Landslide")),
        200:(2, T("Roads Brodken")),
        201:(2, T("Bridges Broken ")),
        300:(3, T("Buildings Collapsed")),
        301:(3, T("People Trapped")),
        400:(4, T("Power Failures")),
    }

So ID 1~99 are major categories. ID 100~199 are under 1st Category "Nature Disaster". 200~299 are under "Transport".

If someone gonna create a new category, he *should* have a look at "THE NATIONAL STANDARD FOR INCIDENT RECORDING" ​http://rds.homeoffice.gov.uk/rds/pdfs08/countnsir08.pdf

TODO: There should be "Please refer to the link of 'Make a request' for the need of helps" in the page before creating a incident report.

It is what I can think of now to get most benefit for current usage and fine for future development.

For now the code will only show the sub categories.

If it's ok, the diff code is on ​http://bazaar.launchpad.net/~keitheis/sahana-eden/edentrunk/revision/1073

If we had much more time and the amount of categories went out of control, we can try the top-down way of selecting gis location. (I've tried and find it needs much more effort to make it work.)

Where there are hierarchies (such as roadway.roadwayClosure) provide a JS widget to split this into a hierarchical selector.

---

BluePrints