Table of Contents

Requirements Specifications

Missing Persons Registration

  • Ability to report a missing person without logging in
  • Ability to report a found person without logging in
  • Need to manage access and security - NO Public Access to missing or found persons lists!!!
  • Missing Persons Data schema to match PFIF? (See http://zesty.ca/pfif/)
  • See ICRC Missing Persons Registry and http://www.haitianquake.com for compliance
  • Localize MPR to match local requirements
  • Configure MPR to match mission requirements
  • Get up a public site by end of the day (15 January 2010)

Deceased Persons

  • “Deceased” can be status flag in MPR
  • Need to record where body recovered and where it was sent
  • How do you deal with bodies that are not identified? Record where found, descriptors (height, weight), digital photo, identifying marks, clothing, jewelry…
  • Remove requirements for name, address – enter as “Jane Doe”

Disaster Victims and Survivor Registration

  • Ability to report survivors/injured victims (DVR functionality)
  • Where are they sent for treatment? (Shelter Registry functionality)
  • We need to track where found/rescued and where sent?
  • Do we check in people when they arrive or just track where sent?
  • Register/check-in individuals and families at shelters (new)
  • Cross-reference/run searches against missing persons registry (new)

Shelter Registry (new)

  • Ability to track location of shelters, capacity, current population, etc. (out of box Shelter Registry functionality)

Synchronization of Sahana Data

  • Need to be able to synchronize this data between different Sahana instances
  • Need to be able to sunchronize data between Sahana and SahanaPy instances

Open Standards and Integration

  • Need to publish data via KML or GeoRSS or RSS or EDXL so others can consume our data.
  • Pull data from InSTEDD GeoChat's Haiti group - see GeoChat API Information Docs
  • Pull data from Ushahidi (http://haiti.ushahidi.com)
  • Display KML from UAS data?
  • Note: need trunk or Sahana-Camp-Roberts branch to do this because of openlayers requirements

Organization Registry

Requirements for Relief Activity Gap Report

  • Objective help responders find affected areas that are not being covered by various relief services
  • the activity can be associated to a registered organization (or not - it might be spontaneous volunteers)
  • the locations should just give a easily referenced set of affected areas where services are need. They might be based on the jurisdictions, but sometime they would not be so we cannot tie it down to a jurisdictional hierarchy
  • The gap reports provides a matrix of
    1. affected locations vs relief service coverage (e.g. food health)
    2. affected locations vs organizations working in that location (a matrix filtered by relief service category)
  • In stage 2 the locations can be associated to a polygon and map area
    1. a map based report of coverage

Sample Data: http://3w.unocha.org/WhoWhatWhere/projectMatrixReportFwt.php?uSite=ocha_na_ht&repId=1

Volunteer Management

Request Management System

  1. put word out that people on the ground can send [Name location status/message]
  2. SMS submitted, with varying levels of structure/detail
  3. The SMS are received by Bart in Holland
  4. Passed by RSS to Ushahdi, who add them to a database
  5. Message is served by Ushahdi so that volunteers can analyze them and add names, location and type of message to a structured form.
  6. The messages (now with structured data) are passed off to orgs (via Sahana) that can do something about the issue

Thus the Sahana RMS needs the following functionality

  • Ability to read a standard GeoRSS tag for aid/pledge requests
    • we need to track these SMS requests for manual processing and entry into the RMS system (so we need a read/processed queue)
    1. click to turn message into a geolocated request (A) or pledge (B)
  • A) Make Request : As data captured for the initial request all we need to capture is
    1. request contact details (name, mobile)
    2. location - free text* (name of camp, name of org, name of distribution point)
    3. priority
    4. geolocation (optional taken from GeoRSS)
    5. representing what org/group - free text*
    6. serving # people (optional)
    7. Requested items: list of
      1. item (free text*), quantity (numeric), unit
    8. see if there are matching pledges (optional) → goto step D)
  • B) Make Open Pledge:
    • same as above for a pledge ( s/requested/pledged/ )
  • C) Fulfillment Request with new pledge
    1. pledge contact details (name, mobile)
    2. location - free text*
    3. representing what org/group - free text*
      1. item, quantity (numeric) fullfilled (next to requested items, requested quantity, fixed unit)
    4. status - pledged, in transit, delivered
  • D) Match Open Pledge to Request
    1. allocate parts of pledge to request (substitute from pledge and add to request)
  • E) Report: Unmet requests table
    • filtered by
      • requested items
      • date (age)
      • priority
      • smart - priority then oldest first
      • proximity
    • geoRSS feed
    • ones that can be matched by requests highlited
  • F) Report: New pledge table
    • geoRSS feed
    • filtered by
      • pledged, in transit, delivered

Note: free text* is best as an AJAX lookup to avoid data entry errors


Personal Tools