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.
Unique Identifiers
Each record should have a unique identifier. To prevent duplication, all sites that can import/export to one another should use the same identifiers for the same records and dropdown items.
It might also be necessary to identify an identification number for each employee that can be printed on forms and other paper documents used for updating the system. If used consistently, this identification number would quickly allow a data entry person to access a person's record if it already exists in the system. The identification number will vary from country to country.
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
As much as possible, these standard lists should be set up when the system is initially installed at the central level.
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 district or 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 (preferred) or via physical transfer on USB or CD.
In case the data transfer is not completed or is interrupted, there should be a rollback feature. This would enable the system administrator to roll back the data to the state it was in before the transfer was started and restart the transfer from the beginning, rather than try to determine where the transfer was interrupted or what data were not transferred.
Issues
Person A leaves employment in one district/facility and enters employment in another district/facility.
- How are duplicate records prevented?
- How is that person's data shared?
When Person A leaves employment in District A, District A updates the person's record as terminated. District A updates the central server with this change. However, Person A may be employed in District B before this update occurs.
District B creates another record for Person A when s/he is employed and updates the central server with the new record. Now there are two records existing for Person A.
District B does not have access to Person A's record in District A, so District B cannot know Person A's work history.
Scenario 1
Whenever an update occurs to the Central Server, the data manager for the system is alerted to potential conflicts. Items that might be compared are names and unique identification numbers.
At the Central Server level, the data manager must have a method for merging duplicate records. This currently does not exist in the system.
The merged record is then pushed back down to District B.
Scenario 2
Basic people data is pushed from the central server to all sites: name, position, employing facility, identification number.
Before District B creates a new record for the employee, they are required to search the system for an existing record. If a match is found, any new data for that person is appended to the existing record so that the same identifiers are used.
District B can request from the central server to transfer the employee's record ownership to them. If approved, the entire record is pushed down to District B and District B can now access the full record but cannot update the employment history at other districts.
Scenario 3
District A and District B maintain their own records for Person A's employment in that district. The two records are never merged at the district level.
At the Central Server level, the data manager is alerted when two records exist for the same person, via the unique identification number. The data manager can then link the two records for reporting purposes.
The linked or merged data is not pushed back down to the district level.
Questions for the Countries/HRIS Advisors
- What systems exist for districts/facilities to inform the Ministry of Health of personnel changes: hires, fires, transfers, promotions, etc.?
- What paper forms exist to support these systems? (provide examples)
- Are any identification numbers used to identify employees of the public health system? Are they unique within the entire system?
- How are hires, fires, transfers, salary changes approved, and by whom?
- What happens when there are breakdowns in the system, i.e., a district doesn't inform the central Ministry of personnel changes?
- What are data privacy and security issues or concerns between facilities, districts and the central Ministry?
- Provide any standard lists such as post lists, job classification/codes, salary bands, etc.
