Difference between revisions of "Understanding IMSMA Information Model"
Line 1: | Line 1: | ||
− | *[[Data | + | {{TOC right}} |
− | *[[Field Reports and Current Views | + | |
− | + | ==Data Types== | |
+ | ===Core Data=== | ||
+ | In the IMSMA<sup>NG</sup> information model, items are the containers for mine action core data. An item is an area, activity or event that a mine action programme records information about and stores in IMSMA<sup>NG</sup>. There are six categories of items, which are described in the table below. Each category can be characterized by a type that reflects whether the item is designed to track process or activity information or the object or product of an activity. | ||
+ | |||
+ | |||
+ | {| class="wikitable" | ||
+ | |+ Items | ||
+ | ! Item | ||
+ | ! Description | ||
+ | ! Type | ||
+ | |- | ||
+ | | Hazard | ||
+ | | Information about an area affected by a hazard | ||
+ | | Object/Product | ||
+ | |- | ||
+ | | Hazard reduction activity | ||
+ | | Information about an activity to survey, clear, or reduce the threat of a hazard | ||
+ | | Process/Activity | ||
+ | |- | ||
+ | | Accident | ||
+ | | Information about an event involving a hazard | ||
+ | | Object/Product | ||
+ | |- | ||
+ | | Victim | ||
+ | | Information about a person injured or affected by a hazard | ||
+ | | Object/Product | ||
+ | |- | ||
+ | | Mine Risk Education (MRE) activity | ||
+ | | Information about an activity designed to inform or educate people about hazards | ||
+ | | Object/Product | ||
+ | |- | ||
+ | | Quality Management (QM) activity | ||
+ | | Information about an activity to control and monitor the clearance and/or reduction of hazards or hazard reduction activities | ||
+ | | Object/Product | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | |||
+ | Items are entered into IMSMA<sup>NG</sup> by means of a field report. Typically, each category of items has its own field report template for recording information specific to that category. When entered into IMSMA<sup>NG</sup>, all field report items must be assigned to a location, which is tied to the country’s gazetteer, or political or administrative structure. The items can then be traced back to the country structure so that users can easily report data such as the number and size of hazards within a particular province. | ||
+ | |||
+ | Part of defining and documenting an information model includes defining the useful information attributes for each IMSMA<sup>NG</sup> item. IMSMA<sup>NG</sup> comes with more than 1,000 data elements already defined as well as the capability to create additional custom-defined fields (CDFs). This makes it important to critically assess which data elements are useful to a programme for decision-making, analysis and reporting and to focus on those while ignoring data elements that don’t provide additional value. Limiting information to only that which is useful to the programme provides long-term benefits including reducing the data collection and data entry burden and improving system performance. And, while many data elements may be collected for each IMSMA<sup>NG</sup> item, some elements may be more important for analysis than others. For example, whether a victim has been injured or killed may be more important for analysis than the victim’s nationality. | ||
+ | |||
+ | |||
+ | {| class="wikitable" | ||
+ | |+ Item Subcategories | ||
+ | ! Item | ||
+ | ! Subcategory Examples | ||
+ | |- | ||
+ | | Hazard | ||
+ | | | ||
+ | * Battle area | ||
+ | * Dangerous area | ||
+ | * Minefield | ||
+ | * CHA | ||
+ | * UXO spot | ||
+ | |- | ||
+ | | Hazard reduction activity | ||
+ | | | ||
+ | * Clearance | ||
+ | * Completion survey | ||
+ | * Technical survey | ||
+ | * Progress report | ||
+ | |- | ||
+ | | Accident | ||
+ | | | ||
+ | * Demining accident | ||
+ | * Mine accident | ||
+ | |- | ||
+ | | Victim | ||
+ | | | ||
+ | * Civilian | ||
+ | * Deminer | ||
+ | |- | ||
+ | | Mine Risk Education (MRE) activity | ||
+ | | | ||
+ | * Peer-to-peer | ||
+ | |- | ||
+ | | Quality Management (QM) activity | ||
+ | | | ||
+ | * Quality management | ||
+ | * Quality control | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | |||
+ | Each of the six categories of items can be divided into subcategories or types so users can collect information for each subcategory. For example, users can specify different types of hazards such as dangerous areas, confirmed hazardous areas (CHAs), minefields and battle areas and manage each kind of hazard differently. Using subcategories, information managers can: | ||
+ | |||
+ | * create separate workflows for each type of hazard | ||
+ | * create and manage separate data entry forms | ||
+ | * differentiate between item categories on the map | ||
+ | |||
+ | Additionally, information managers can customise the subcategories so that unused subcategories can be removed and other subcategories added. The same is true for all top-level items within IMSMA<sup>NG</sup>, which lets information managers specify their exact information model, including the relationships among item categories, and adjust the model as their needs change over time. To accurately map the information model for a programme, it’s helpful to evaluate the available item subcategories and determine if changes to the information model in IMSMA<sup>NG</sup> are required. While these values can be customized after system setup, understanding the types of information for each item is critical to implementing an effective workflow in IMSMA<sup>NG</sup>. Table 5 shows examples of the possible subcategories of IMSMA<sup>NG</sup> items. | ||
+ | |||
+ | <b>Document the following decisions about items:</b> | ||
+ | |||
+ | * data elements to be collected and managed in IMSMA<sup>NG</sup> | ||
+ | * data elements that are not predefined in IMSMA<sup>NG</sup> and should be created as CDFs | ||
+ | * particularly important, or key, data elements for the programme | ||
+ | * relevant subcategories for each item | ||
+ | * status values for each item | ||
+ | |||
+ | |||
+ | |||
+ | Below is an example of a fully-documented hazard. | ||
+ | |||
+ | |||
+ | [[Image:Understanding IMSMA Information Model - Example of Documented Hazard.png|center|500px|''Example of Documented Hazard'']] | ||
+ | <div align="center"> | ||
+ | ''Example of Documented Hazard'' | ||
+ | </div> | ||
+ | |||
+ | ===Auxiliary Data=== | ||
+ | In addition to defining the required information for IMSMA<sup>NG</sup> items, it is important to define the relevant information to be collected about auxiliary data. This includes defining and documenting the [[Country Structure]], [[Explosive Ordnance]], [[Organisation]] and [[Place]], such as military bases, hospitals and cultural sites; any additional CDFs that should be created; and any subcategories for each of the auxiliary data types. | ||
+ | |||
+ | |||
+ | <b>Document the following decisions about auxiliary data:</b> | ||
+ | |||
+ | * data elements to be collected and managed in IMSMA<sup>NG</sup> | ||
+ | * data elements that are not already configured in IMSMA<sup>NG</sup> and can be created as CDFs | ||
+ | * relevant subcategories for each data type | ||
+ | |||
+ | |||
+ | Below is an example of a fully-documented place. | ||
+ | |||
+ | |||
+ | [[Image:Understanding IMSMA Information Model - Example of Documented Auxiliary Data.png|center|500px|''Understanding IMSMA Information Model - Example of Documented Auxiliary Data'']] | ||
+ | <div align="center"> | ||
+ | ''Understanding IMSMA Information Model - Example of Documented Auxiliary Data'' | ||
+ | </div> | ||
+ | |||
+ | ==Field Reports and Current Views== | ||
+ | |||
+ | ==Reconciliation Process== |
Revision as of 17:04, 27 November 2012
Data Types
Core Data
In the IMSMANG information model, items are the containers for mine action core data. An item is an area, activity or event that a mine action programme records information about and stores in IMSMANG. There are six categories of items, which are described in the table below. Each category can be characterized by a type that reflects whether the item is designed to track process or activity information or the object or product of an activity.
Item | Description | Type |
---|---|---|
Hazard | Information about an area affected by a hazard | Object/Product |
Hazard reduction activity | Information about an activity to survey, clear, or reduce the threat of a hazard | Process/Activity |
Accident | Information about an event involving a hazard | Object/Product |
Victim | Information about a person injured or affected by a hazard | Object/Product |
Mine Risk Education (MRE) activity | Information about an activity designed to inform or educate people about hazards | Object/Product |
Quality Management (QM) activity | Information about an activity to control and monitor the clearance and/or reduction of hazards or hazard reduction activities | Object/Product |
Items are entered into IMSMANG by means of a field report. Typically, each category of items has its own field report template for recording information specific to that category. When entered into IMSMANG, all field report items must be assigned to a location, which is tied to the country’s gazetteer, or political or administrative structure. The items can then be traced back to the country structure so that users can easily report data such as the number and size of hazards within a particular province.
Part of defining and documenting an information model includes defining the useful information attributes for each IMSMANG item. IMSMANG comes with more than 1,000 data elements already defined as well as the capability to create additional custom-defined fields (CDFs). This makes it important to critically assess which data elements are useful to a programme for decision-making, analysis and reporting and to focus on those while ignoring data elements that don’t provide additional value. Limiting information to only that which is useful to the programme provides long-term benefits including reducing the data collection and data entry burden and improving system performance. And, while many data elements may be collected for each IMSMANG item, some elements may be more important for analysis than others. For example, whether a victim has been injured or killed may be more important for analysis than the victim’s nationality.
Item | Subcategory Examples |
---|---|
Hazard |
|
Hazard reduction activity |
|
Accident |
|
Victim |
|
Mine Risk Education (MRE) activity |
|
Quality Management (QM) activity |
|
Each of the six categories of items can be divided into subcategories or types so users can collect information for each subcategory. For example, users can specify different types of hazards such as dangerous areas, confirmed hazardous areas (CHAs), minefields and battle areas and manage each kind of hazard differently. Using subcategories, information managers can:
- create separate workflows for each type of hazard
- create and manage separate data entry forms
- differentiate between item categories on the map
Additionally, information managers can customise the subcategories so that unused subcategories can be removed and other subcategories added. The same is true for all top-level items within IMSMANG, which lets information managers specify their exact information model, including the relationships among item categories, and adjust the model as their needs change over time. To accurately map the information model for a programme, it’s helpful to evaluate the available item subcategories and determine if changes to the information model in IMSMANG are required. While these values can be customized after system setup, understanding the types of information for each item is critical to implementing an effective workflow in IMSMANG. Table 5 shows examples of the possible subcategories of IMSMANG items.
Document the following decisions about items:
- data elements to be collected and managed in IMSMANG
- data elements that are not predefined in IMSMANG and should be created as CDFs
- particularly important, or key, data elements for the programme
- relevant subcategories for each item
- status values for each item
Below is an example of a fully-documented hazard.
Example of Documented Hazard
Auxiliary Data
In addition to defining the required information for IMSMANG items, it is important to define the relevant information to be collected about auxiliary data. This includes defining and documenting the Country Structure, Explosive Ordnance, Organisation and Place, such as military bases, hospitals and cultural sites; any additional CDFs that should be created; and any subcategories for each of the auxiliary data types.
Document the following decisions about auxiliary data:
- data elements to be collected and managed in IMSMANG
- data elements that are not already configured in IMSMANG and can be created as CDFs
- relevant subcategories for each data type
Below is an example of a fully-documented place.
Understanding IMSMA Information Model - Example of Documented Auxiliary Data