Casualty / Victim Tracking System
General
Casualty and Victim data is stored in IMSMA in the tables
- tblIncAccCasualty (linked with tblIncAccAccident or tblIncAccIncident)
- tblSurvey1MinedAreaVictim (linked with tblSurvey1MinedArea)
based on the origin of the data (LIS - recent victim or accident/incident - casualty).
It is a system feature that Survey1MinedAreaVictims are an element of basic information, an 'approximation of the problem' and that they mainly influence the IMPACT SCORE calculation >> it is not a strict collection of facts / it is rather a 'hint'.
Mine/De-mining victims are persons where factual information is known; they were seen, registered, they can be visited. They do really exist and all information should(!) be 100% correct.
It is also a feature (which might be disputable) that survey victims (see primo) cannot just be muted/copied to become 'Accident' victims/causalities (see secundo) - they have to be inputted a second time (the developers felt a need for this procedure for data security reasons).
Situation in Afghanistan
In Afghanistan the Survey1MinedAreaVictims data is of good quality from the just completed LIS and will be maintained by the pre assessment teams. Mine victims and mine accidents (IncAccIncident)are based on reports from ICRC (and some other organizations) and is entered into IMSMA without prior verification by our own resources. It's planned to send Quality Management and Inspection Team (QMIT) to the location of the accident to verify the report and take the coordinates by GPS.
For us it's important to have a link between tblIncAccIncident and tblSurvey1MinedArea!
We can't make the link via gazetteer because it is still changing to adjust to the modified country structure and to correct errors (also see attached file).
Motivation
Victim data can be used not only for planning purpose but also for victim support in the form of a victim tracking system.
We have to keep the LIS up-to-date and associate a victim with the hazardous area and make sure that all known incident locations are finally reported in IMSMA.
Solution (Updated 2005-07-11)
The following key decisions/activities will lead to a joint victim database:
- An FK relationships in tblIncAccIncident to the areas (hazards) as in tblIncAccAccident required (code change).
- Dangerous area record added when an incident occured but no SHA recorded.
- A dummy record will be maintained in the tblSurvey1MinedAreaVictim for each recent victim (to allow a correct impact calculation) and a UDF keeps a foreign key relationship to a record in tblIncAccCasualty. The ID number of the victim in that entity will be shown.
Result / Outcome
- Joint victim database
- Victim tracking system
- Update procedure for LIS data
