2,186
edits
Changes
no edit summary
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 IMSMANG 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.
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.
====Document the following decisions about items:====
* 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
====Example: Fully Documented IMSMA<sup>NG</sup> Hazard====
Hazard
* Hazard reductions
Subcategories
* Battle areas
* CHA
* DHA
* Minefield
* SHA
* UXO spots
Status values
* Open
* Worked on
* Closed
Key fields
* Priority
Other required fields
* ________________
[[Image:Understanding IMSMA Information Model - Documenting Items.png|center|500px|''Documenting Items'']]
