Import and Export Data

The Problem

In most countries, there is a need to manage human resources data at the lowest level of employment: the hospital, clinic or local government. But data must be aggregated to the national level for reporting and decision making.

In many areas, Internet infrastructure is not sufficient to support updating a central system from decentralized locations. We developed Offline iHRIS as a solution where Internet is unreliable or unavailable.

When instances of iHRIS are installed in several different locations, whether Offline iHRIS or a server-based version, there is a need for exchanging data between systems. Data must be pushed up from the local system to the central system for reporting. Standard data lists must be pushed down from the central level to the local level to update dropdown menus. There is also the issue of people moving to other facilities or districts and how their data can follow them or how duplicates in the system can be prevented.

Finally, security and privacy are concerns. There may be reluctance for districts or facilities to share data with one another.

Server Hierarchy

There are two proposed methods for managing server hierarchy:

Method 1: Central Server is for reporting data only; all records are updated via separate sites underneath the Central Server.

   1. Central Server
      a. Ministry of Health employees -- updated at the central level but via separate site
      b. All regional hospitals -- updated at the central level but via separate site
      c. District A
         i. All clinics
         ii. Facility A
         iii. Facility B
      d. District B

Method 2: Central Server is for reporting data and for updating records housed at the central level

   2. Central Server with MOH and regional hospital records
      a. District A with clinic data
         i. Facility A
         ii. Facility B
      b. District b with clinic data

For ease of data synchronization, Method 1 is preferred. To alleviate confusion for people maintaining records at the central level, we can customize an entry page to facilitate accessing reports and updating records housed in separate sites but at the central level.

Data Standards (Dropdowns)

Data standards are enforced via dropdown menus for common elements, such as geographical locations, job classifications and jobs, cadres, marital status, etc. In a standard installation, the data manager can update these lists. With multiple decentralized installations, this can lead to discrepancies in spelling or phrasing for data elements that are the same.

To prevent this, the base data should be set and enforced at the central level. These standard data elements should be pushed down whenever updated to all installations in the hierarchy. At the lower levels, these data items should not be editable.

The exceptions might be:

• facilities
• positions

Updating Records

Person records (perhaps also facility and position records) should only be updated at the level of employment, the lowest level in the hierarchy where the health worker is actually located. For example, a facility employee's record is created and updated at the facility level, but is not edited at the central level. This will prevent discrepancies among records.

At regular intervals, there should be uploads through the hierarchy. For example, the facility data is uploaded to the district. The district's data is then uploaded to the central server. This enables the facility to report on all health workers employed at the facility, the district to report on all health workers employed at all facilities in the district, and the central Ministry of Health to report on all health workers employed in all districts.

Data transfer can occur over a network or via physical transfer on USB or CD.

Unique Identifiers

Each record should have a unique identifier. To prevent duplication, all sites should use the same identifiers for the same records.