You are on page 1of 16

THE CHALLENGE OF

“TRANSLATING”
HEALTH
INFORMATION
SYSTEMS FROM ONE
DEVELOPING
COUNTRY CONTEXT
TO ANOTHER
CASE STUDY FROM MOZAMBIQUE
INTRODUCTION

• Translation of open-source software designed and developed for supporting Health Information
Systems of South Africa to Mozambique
• Translation of language, adapting the software to the different contexts of use.
• Challenge to translation- very different socio-political-cultural contexts
• “Pragmatic Balance”- Rolland and Monteiro’s (2002) argument
• An analysis of this process helps to shed light on the simultaneous processes of
internationalization and localization of HIS.
WHO STANDARDS OF HIS

• District- designated as the hub for all information management activities. (Data from the health units
are sent to the district where it is aggregated and then sent to the province and national levels.)
• Multiple donor-supported vertical programs operating
• Enable the calculation of health indicators such as immunization coverage
THEORITICAL CONSIDERATIONS

• Processes of internalization, localization and globalization


• Translation of software- two types.
A) General Business Domain Application (GBDA)
B) Special Business Domain Application (SBDA)
• The translation processes of SBDAs are thus more complex and require greater time and investment
of end users as compared to GBDA.
(The case-translation process of a SBDA software related specifically to the domain of PHC)
PROCESS OF DESIGN & DEVELOPMENT OF DHIS

Understanding the health information


needs of the health department and
how the DHIS could help support it

Testing the DHIS in the pilot


sites, and taking necessary
correction action in “the
specifying learning” phase

Setting up the multidisciplinary team


and establishing the strategy for
DHIS localization
Using the prototyping methodology
for developing and using various
translated versions of the software
DHIS SOFTWARE MODULES AND DATABASE FILES
Modules Database files
The modules represent the various user interface and • The database file represent the Backend of
represent the Frontend of DHIS. DHIS stores information about data elements,
Examples- data element categories, indicators,
• Routine monthly data module – allows data entry, definitions, organizational unit data, and semi-
verification and analysis of monthly data from the permanent data for example related to
PHC and hospital services. population.
• The tuberculosis (TB) module enables entry of • Classification of database files- It can be
routine TB data entry, verification and analysis. based on the organizational structure of
• The Report Generator module is used for country like for Mozambique-
generating and accessing reports on any of the data I. National
files. II. Provincial
• The Client Satisfaction Survey module is used to III. District and
capture and analyze the client satisfaction survey IV. Health Unit.
data
DHIS Software Features
DATA DICTIONARY
INDICATORS Web based application storing the
Identified and handled nationally approved names and
definitions for all the data
according to the
elements that are in common use
numerator, denominator
1 3
throughout the country.  
and indicator type

TOOLS FOR DATA


QUALITY CONTROL
Allows checking of the quality 2 COMMUNITY DATA
Provide the definitions 4
of data entered by setting the for the different semi-
minimum and maximum ranges permanent data elements,
for all the data elements.  such as population
Validation check once a facility’s
groups and targets.
data has been entered for
the month
DHIS Software Features

HISPML
DHIS INSTALLATION CD
(HISP MULTILANGUAGE LIBRARY)

Separate database module storing the


Includes user manual, additional support
text strings visualized in different user-
software tools including various
interface screens of the current
Microsoft service releases/packs
FRONTENDS

Allows to translate DHIS to all MS


WINDOWS 2000/XP supported
All the complementary and
languages, whereby by selecting the
supplementary resources available.
locale, the text strings are automatically
visualized in the different screens.
THE CASE : TRANSLATION AND ADAPTATION OF
HMIS
IN ASSOCIATION WITH THE 3 DOMAINS OF IMPLEMENTATION
• There was agreement among the HMIS group in Mozambique to at first execute for testing purposes just the
Routine Monthly Data module of the HMIS.
• The underlying utilization of HMIS was to automate the current paper framework and fundamental strategies
from the current Public Health Information System, called SIS.
• In doing the interpretation, abilities and skill was needed from the area of software engineering, medication, and
general wellbeing.

PROBLEM FACED:
• Albeit none of the HMIS colleagues were local English speakers, and neither did they have any related
knowledge in language interpretation overall and of programming specifically, the principal model was
fundamentally an yield of the joined exertion of this group, upheld by authorities from the Ministry of Health.
Factors based on the 3 domains with effective implementation identified in the
case:

1. TECHNICAL
Usability, system performance, integration and interoperability, stability and reliability adaptability and
flexibility cost, accessibility and adaptability of hardware.

2. SOCIAL
Attitudes and concerns, resistance and workarounds, expectations, benefits/ values and motivations,
engagement and user input in design, training and support, champions, integration with existing
work practices.

3. ORGANIZATIONAL
Getting the organization ready for change, planning g leadership and management, realistic
expectations, user ownership, teamwork and communication, learning and evaluation.
Some words did not have direct translation in Accessing the releases/packs from the internet requires
Portuguese. In this case, the team was forced to Language Rules and (i) availability of internet connection and a (ii)
perform a partial or intermediate translation, mixing Lack of Portuguese reasonably fast link. Such a downloading exercise could
English and Portuguese text. Terms from English last for hours or even days in Mozambique.
The dictionary could help in the translation of
simple strings but not of strings of strings.
Portuguese equivalent were much
Translation was performed focusing longer than those used in English. This
more on the technical terminology and Inadequate Length of issue of length had implications for the
aspects from the computer point of Knowledge Strings user interfaces, the description and
view, rather than on developing the distribution or location of the different
correct meanings of technical health CHALLENGES
buttons, the layout of the screens and
terminology which led to improper EXPERIENCED quality of the video adapters.
meanings of terms that caused DURING THE
problems for the users.
TRANSLATION
PROCESS
The hierarchical organizational structure
of the health system in Mozambique is Different There was a problem of different and
Different Naming
different from South Africa. A dummy Organizational inconsistent naming conventions of the
Conventions
organizational layer has to be added to Structures different organizational units in
the Mozambican organizational structure Mozambique. Thus, the naming
to allow for the compatibility of levels. convention needed to be changed.
ANALYSIS

DHIS:
• The DHIS described earlier is composed by a set of modules, each with specific functionality.
• Viewed from the perspective of a SBDA, the DHIS gives space for specific countries or
organizations to decide, according to their needs and priorities, what do adopt and localize first.
• In Mozambique, it was agreed to focus first on the localization and translation of the monthly
data module (FRONTEND), which still allowed us to use the software.
• Given the relatively advanced nature of the DHIS implementation process in South Africa, we
found the user manual provided with the software was developed for users with high computer
skills, which was definitively not the case in Mozambique, especially in the rural areas.
GBDA:
• In contrast, localizing a GBDA implies taking care of primarily all the engineering aspects before the
software is released for distribution.
• A primary focus on the technical aspects implies that the context specific meanings of use are ignored. As
a result, the users can feel alienated and resist the system.

SBDA:
• In the SBDA, the source (developers in South Africa) and the target (localization team in Mozambique)
teams are expected to co-develop the software, and the source counterpart acts as a supervisor, ensuring all
the desired features at the required standard are included.
• However, such a development model assumes the existence of local capacity, and not only about the
technical features of the software, but also of domain (medical) and context of use (public health).
• This assumption, while initially incorrect, however has positive implications in the long run
GBDA SBDA

What should be • Translate interface • Translate interface, documentation


translated • Keep functionality • Localize/translate Functionality
Competence needed • Computer skills • Computer skills
• Technical expertise relating to formats, standards • Application domain experience & knowledge
• Professional language and software translation • Contextual language & software translation
How • Long-term iterative process of translation according to • Short-term iterative process of translation according to LOCAL
INTERNATIONAL market requirements requirements
• Separate in time and space interface translation from • Not separate in time and space interface translation from
Functionality functionality
Localization • Technically enable the software to support foreign languages • Technically enable the software to support foreign languages, the
and basic formatting required required formatting and the meanings, e.g. symbols, colours
• Vendor or corporate-driven • Require more time and effort for understanding the culture,
• Provide tools and utilities for local customization of Interface meanings
• Through localizers • In-house, contextual process of development
• Multidisciplinary team representing different knowledge domain
• Full involvement of potential users
• Provide tools and utilities for local customization of interface
and functionality

Internationalization • Semantic factors most important • Context factors most important


• The commercial restriction does not allow for providing the • Internationalization as first step
source code • Provide the application and source code
• Through Internationalizers
Globalization • Applicable • Not applicable
• Same standard across countries and cultures
• Through globalizers
CONCLUSION

• The primary concern was about understanding the processes involved in translating HIS in the context of
developing countries.
• Specifically, the focus was to analyze the practical challenges of translating a HIS designed and developed in
South Africa to be subsequently used in Mozambique.
• Two application domain perspectives were distinguished, GBDA and SBDA, and the differences in their
internationalization and localization processes were identified.
• The evident tensions between the needs for internationalization and localization models were highlighted and
five specific challenges were identified. These challenges need to be considered for purposes of both the
language translation and adapting the HIS in varying contexts of use.
• Sensitiveness to contextual differences must be taken into account when designing, developing or
implementing systems.

You might also like