1.3 IMSMA (Information Management System for Mine Action)

Introduction to IMSMA

IMSMA is developed by the Center for Security Studies and Conflict Research at the Swiss Federal Institute of Technology Zurich (ETHZ) on behalf of the Geneva International Center for Humanitarian Demining (GICHD) and is part of Switzerland's effort to strengthen humanitarian de-mining. The Geneva International Centre for Humanitarian Demining provides the IMSMA Field Module free of charge to the mine action community. More information on IMSMA can be found in annex 6.

IMSMA is the UN-approved standard for information systems supporting humanitarian de-mining. The intent is to collect standardised mine related data and manage it in a standardised system using powerful statistical and geographical tools.

Set-up as a networked multi-user system, IMSMA enables several users to enter and evaluate their data simultaneously. The system consists of two modules one of which is the IMSMA field module which is designed for use by Mine Action Centers (MACs). This module is intended to assist MACs improve capabilities for coordinating, prioritizing, and executing de-mining activities.

Just prior to the start of the National Level One Survey project (April 2000), CMAC had been provided with a copy of the first version of IMSMA by GICHD. Two technical officers from CMAC had participated in a training course given in Switzerland.

Role of IMSMA in the Cambodia Survey

At the commencement of the L1S the decision was taken between CMAC and GeoSpatial database staff and management not to actively use IMSMA for data entry purposes in the survey process. The reasons for this decision had to do with:

The existence of a CMAC database that was in active use, that had been developed in FoxPro, and the existence of a prototype L1S funded by the EU which had also used FoxPro as its data management software;

An expressed need to collect data beyond the standardised data permitted in IMSMA, based on the previous experience with L1S in Cambodia, and the limitation of IMSMA in having only five user definable fields available at the time the survey was being designed; and IMSMA is a multi-user networked system that was thought at the time to be vulnerable to power failures with a significant effort required for recovery before resumption of normal operations.

To further amplify this last concern; the experience of our staff in Phnom Penh with power systems and failure was that we could expect a high failure rate of computer components, and that the technical expertise to maintain our computer systems had to be found in-house. The system we designed allows for the failure of any component at any time without loss of a substantial amount of data. We also made sure that there would be a minimum loss of working time for those data entry staff not directly affected by the component failure. Our system uses individual standalone computers for data entry stations, networked for backup and assembly of data. Any workstation may be used for the aggregation task, and are therefore peers in the system. The IMSMA alternative would have relied on a single computer to never fail - the IMSMA server. On loss of this server, no data entry would have been possible until another computer could be brought up, IMSMA installed, and then the clients pointed at it again. This failure was considered to be too likely a possibility under the conditions in Phnom Penh to risk the loss of function in the data centre.

On the question of the database design; CMAC already had a locally developed and accepted questionnaire, which formed the starting point from which we developed a new questionnaire, that met both the local community needs at CMAC and the international standardisation needs of UNMAS. At the time there were only five user-defined fields available in each IMSMA table, which would not allow us to carry all the information required for the local survey in the IMSMA database. The current version of IMSMA, as of version 2.2, carries 20 user-defined fields per table, which might be sufficient.

IMSMA Converter

Although the decision had been taken not to use IMSMA for data entry there was an active need expressed by both the Government of Canada, CMAC and the UNMAS that results from the survey should be available in IMSMA to enable the participation of Cambodia in the Global Land Mine survey coordinated by the Survey action Centre in Washington DC. Availability of the survey data in IMSMA is a condition for UN certification of any survey to ensure compatibility of survey data from different countries.

Given these needs it was decided to build a conversion routine that would enable data from the FoxPro based data entry system to be entered in the IMSMA Field Module. We first provide a short explanation of the principles on which the two databases have been designed.

Design Principles of the Cambodia L1S and IMSMA Databases

The IMSMA database and the Cambodia National L1S data base were designed with a similar structure in mind- namely the survey of villages, recording socioeconomic impact for the village, a list of known mined areas and a list of casualties in these mined areas. The L1S information was collected in a way that was intended to be compatible with the IMSMA database system.

The L1S database was developed for use by Khmer-speaking data entry staff to enter data from the Khmer-language field survey forms. The requirements of the Cambodian coordinating agency (CMAC) included a variety of information that is not collected in the IMSMA system as it existed at the time. An example of this is the prevalence of female-dominated households in the village.

The broad conceptual frameworks of the L1S and the IMSMA database are similar. The task of recomposing the data from the L1S for the IMSMA database consists of identifying the fields that contain the same data in the two databases, and filling the IMSMA database with the contents thereof. The village table in the L1S (l1vill.dbf) is used to fill the table tblSurvey1 in the IMSMA database.

The IMSMA database is designed for remote computers to connect to it for reading and writing data. It exposes its tables through an ODBC connection set up system-wide at the time an IMSMA client was installed. This is documented in the manuals that come with IMSMA.

Data Conversion from Cambodia FoxPro L1S Database to IMSMA

The technical challenges encountered in writing the converter from our database structure to the IMSMA structure were in mapping the fields from one system to the other. Once all the fields were properly cross-referenced, the problem of developing the queries to actually insert the data was relatively simple. The biggest difficulty in referring back and forth between data formats was the use of different unique identifiers in each database. The solution we chose was to generate new unique identifiers in the IMSMA database, and include the L1S unique identifiers in the user-defined fields. Where the data structure requires a reference to another table, an update query processed after the initial insert maintains referential integrity.

The biggest challenge with entering our data into IMSMA is that the two data structures deal with victims differently. When interviewing village leaders, the mined area in which a casualty was injured may not be known, although the leader may be able to demonstrate knowledge of the casualty that suggests that the incident is worthy of being recorded. In this case, we were unable to clearly identify the mined area in which the incident took place, which IMSMA data structure requires for recording the casualty. Our solution was to allocate the casualty to the mined area identified for the village, with the highest number of casualties. A note in a user-defined field explains the situation.

The original conversion routine was designed and tested early in the L1S project. Before completion of the project, a revised version of the Field Module had been released, version 2.2. This necessitated a review and revision of the translator as the table structure for v.2.2 of IMSMA, while similar to the previous version, had introduced some notable differences. New tables had been added and changes made in the indexing of tables.

The tables we are populating in the IMSMA database are the tables that contain the census data and the level one survey data. We populate the census data (tblCity, tblSubdistrict, tblDistrict, tblProvince, tblCountry) from the 1997 Cambodian National Village Census. The L1S tables (tblSurvey1, tblSurvey1MinedArea, tblSurvey1MinedAreaVictim, and some ancillary tables) were populated directly from data we collected.

We created a standalone Foxpro program to do the conversion. It uses the data definition from the L1S database to generate a series of SQL queries to insert the data from the L1S into an IMSMA server installation. The unique identifiers required are generated at runtime.

The product of the conversion process is a populated IMSMA database to install on top of a generic IMSMA installation. This file can simply be copied, or installed using an installation program. This will provide the necessary files for a central agency installation of the database. From that central agency installation, an export can be made using normal IMSMA methods for transmitting the data to a central international agency.

Back to Section 2.1 Inception Mission
Back to Section 2.3 Developing the Questionnaire
Next Section - 1.4 CIDA Funding and Co-operation with CMAC
Back to Table of Contents