Jay J. Strain¹ James J. Strain² Luis G. Ruiz-Flores³ Murali K. Aela⁴

¹ M. D. Albert Einstein Medical Center, Albert Einstein Medical Center.
Correo electrónico: jay_strain@hotmail.com

² M. D. Mount Sinai – NYU Medical Center/Health Service.

³ M. D. Centro Médico Nacional, Ciudad de México.

⁴ M. S. DocOptions, Inc., Tracy, California.

Abstract

Electronic medical record (EMR) systems are becoming a standard for patient care, but are difficult to customize for local, regional, or international use. Particularly in the case of psychosomatic medicine, where diverse sociological, economical, cultural, and political influences may contribute to a patient’s disease state, EMRs have difficulty in being economically implemented. Careful, flexible computer program design, special editing systems to customize graphic user interfaces, and identifying localregional physician experts to assist in translation are keys to making a working application.

We discuss the Micro-Cares™ CISCL Clinical Information System and the programming and customization decisions which have gone into adapting it for multi-language support. Discussed are the EMR design, adaptation for multiple hardware platforms (desktop, laptop and tablet computers, and on hand-held PDA systems), multi-tiered data storage, and customizable language manager, and questionnaire designer. Concepts of flexibly “scaling” CISCL to support the single user, or multiple user, or extensive department/ division personnel are discussed.

Experience with regional testing and use are described, including modifications to the CISCL program that have been extensively user-guided. Finally, we examine standards of approach to multi-language support that have arisen from adapting CISCL to non-Romance-based languages, e.g., Mandarin. Our current experiences are summarized with description of on-going research efforts.

Key words: Software, microcare, computerized medical records systems, psychosomatic medicine, Latin American.

Resumen

Los sistemas de registro médico electrónico (RME) se están convirtiendo en el estándar en cuanto al cuidado clínico del paciente se refiere, pero son difíciles de diseñar a medida para uso local, regional o internacional. Ésto es particularmente cierto en el caso de la medicina psicosomática, en la que diversas influencias de tipo sociológico, económico, cultural y político influyen en el estado del paciente, haciendo que los RME sean difíciles de implementar de manera económica. Un programa de computador diseñado de modo cuidadoso y flexible con sistemas de edición para personalizar gráficas, e identificar médicos expertos en el medio local-regional para que asistan en la traducción son las claves para hacer que una aplicación funcione.

Presentamos el Micro-Cares™ CISCL Sistema de Información Clínica y discutimos la programación y las decisiones tomadas para adaptar el sistema a un soporte multilingüístico. Se discuten el diseño del RME, su adaptación para múltiples plataformas de hardware (computadores de escritorio, portátiles y tablet y sistemas PDA Palm™), sistemas de almacenamiento multinivel, administrador de idioma personalizado y diseñador de cuestionarios. También se discuten los conceptos de “escalonar” el CISCL de manera flexible para soportar un usuario único o múltiples usuarios, o personal numeroso de un departamento o división.

Se presenta una descripción de las pruebas y uso a nivel regional, incluyendo modificaciones en el programa del CISCL que han sido guiados por los usuarios. Para finalizar, examinamos estándares de aproximación en soporte multilingüístico que han surgido al adaptar el CISCL a otros idiomas no basados en las lenguas romance, por ejemplo, el mandarín. Nuestras experiencias actuales se resumen con una descripción de nuestras investigaciones en curso.

Palabras clave: software, sistemas de registros médicos computarizados, medicina psicosomática, Latinoamérica.

Introduction

Electronic medical records have become mandatory in a modern hospital setting. They have been shown to optimize communication between physicians and help limit errors with medication prescribing [1-3]. The electronic systems provide not only a method to assure and optimize completion of patient records, but also a mechanism for tracking resource use. Unfortunately, most computer information systems are expensive, and difficult to install and maintain. Most are originally designed for use in large, multi-disciplinary institutions or wealthy private practices in English-speaking North America. Such electronic record systems are difficult to implement in Central and South America.

Multiple paradigms exist for the creation of electronic medical record (EMR) systems, but making any system useful internationally requires careful system design, protocols for identifying local-regional experts to assist in customization, and provision for a system for rapid editing for regional dialect display. We describe a psychosomatic medical records system, Micro-Cares™ CISCL, and efforts to optimize the program for use towards documenting psychosomatic disease and care at diverse international locations. We further discuss specifics related to patient care tracking in Central and South America, and experiences with customizing computer systems to communicate in Spanish, Portuguese, and additional non- English languages.

Description

Micro-Cares™ CISCL began as a project based on US National Institutes of Health medical records standards available in the 1970’s (e.g., Clinical Information [CLINFO] system, Research Data Entry[RDE] system, etc.) [4,5]. The data structures designed were excellent for capturing data, but confined the user to documenting text or numeric data in a limited “line-byline” fashion. Later graphic user interfaces (GUIs) provided more flexibility in data entry (e.g., Microsoft Windows™-style interfaces, etc.) with ability to pre-define data “forms”. This ongoing development is well documented in previous investigations [6-8].

While language translation of a “form” can be simple to provide, the nature and complexity of conveying medical information made automatic translation problematic. Additionally, the medical data acquired and the medical decision making performed have been found to be dramatically tied to regional information sources, care practices, and customs [see Figure 1]. Medical teaching and training institutions impart to the trainee standards and approaches to medical care that are regionally appropriate but not always universal. Furthermore, psychosomatic medicine is further constrained by an integration of social, economic, cultural, religious, and even political forces that are difficult to model, especially as a generic approach for all psychiatrists. For these reasons, no international standard psychosomatic medical record is in use.

Micro-Cares™ CISCL attempts to address these issues through a flexible, customizable medical record system with 1) a knowledge of consultation psychiatric work practices, 2) custom mechanisms for editing the user interface, 3) a customizable, language-independent report writing system, 4) predefined templates based on “triedand- true”, standardized psychiatric forms, 5) a “Language Manager” which allows the user to view all languages supported in a side-byside fashion, and 6) a custom questionnaire designer which allows the regional user to adapt the CISCL system to specific user needs.

A Knowledge of Consultation Psychiatry Work Practices

Acknowledging that a flexible computer program should “adapt” to its user, Micro-Cares™ CISCL begins with the assumption that each physician may have a work setting that is unique. Some physicians may have desktop computers in every room of their clinic; some may have a laptop that is shared among a group of physicians. Some users may have access to a central computer at the main psychiatric division headquarters, but use only handheld personal data assistants (PDAs) during their “rounds” during the day. CISCL provides a networkbased program that can support all three of these approaches via multiple desktops or laptop units simultaneously linked to a central database [10]. There is also support for remote capture of data via Palm Operating System (OS)-based handhelds. Information is bidirectionally shared to all users of the office or division or department to allow continuity of care. CISCL can be used independently on a single laptop for a single user, or as a more complex, networked, multiuser or even multi-department data collection system, and automatically scales itself to either of these models. This flexibility was believed to be necessary given evaluation of the nomadic nature of psychosomatic medicine consultation services and parallels the workflow requirements of the consultation psychiatrist.

Customized Editing of the CISCL Interface

CISCL has an architecture where the main supporting database is maintained concurrently for each language being supported. It is maintained along side additional secondary databases “tables” (technically called “relational tables”) for each language so that regional and local customization are directly linked to the master database for a particular user. In this fashion, each institution, with local preferences, opens a master database dedicated to their own pre-defined preferences and to their specific patients. Inherent to the structure is a core 100 item database that has thirty years of optimization towards general hospital and consultation psychiatry [11]. Display preferences, local research variables, and additional custom-designed questionnaires are linked to this central data core and are maintained in a fashion transparent to the user.

Traditionally, graphic user interfaces (GUIs) in computer programs were “hardwired” to text descriptors that could not be changed by the user [12]. Because data in a particular field was “predefined”, translation of a program into new languages required changing every display, user item, and supporting text individually. Although some aspects of this older approach are still necessary, more flexible data storage methods exist. CISCL is designed with separated database layers and communication layers. Language customization information can be maintained in separate relational tables or specialized data “resources.”

Using this architecture, multiple levels of customized data presentation are supported. Through the use of “code groups”, reusable data collections (e.g., city names, state codes, department types, patient types, insurance providers, etc.) can be queried for values, and any user can quickly add, edit, or modify them to reflect the local practice environment. And while certain standard code groups may be common to every language, the ability to custom generate new ones is particularly useful where regional-specific data need to be codified for user entry.

To customize the CISCL interface, a native-speaking psychiatry expert or group of experts is identified to assist in translation. Meeting with these physician-psychiatrist experts, who live in the areas to where the CISCL program is to be employed, attention to local race categorization, specific marital status descriptors, local expected referral centers, treatment option trends, health insurance plans, and many other factors are codified and further optimized for guided data entry.

In addition to the coding groups, individual data entry screens are similarly customized. Where this is particularly important is in “laying out” the display for the user to enter data. The graphic user interface (GUI) screens are limited in space or “real estate” and need to have language phrases translated to fit accordingly. For instance, the translation for “Patient Episode Selection” in Spanish is “Selección del Episodio del Paciente”. Since the length of the phrase is significantly longer, a truncated expression may need to be created. Automated translation programs are unable to determine the importance of a particular phase or what can be removed from the phrase and still maintain readability. For these reasons, a knowledgeable regional expert is mandatory.

Structured data entry is provided in CISCL along expected practice work-flow (e.g. demographic, administrative, medication, laboratory, progress notes, etc.) and leads to a selection of custom questionnaires. This provides a standardized “style” to data entry for the individual user. But it also allows institutions to use the CISCL program in the fashion or custom of their current office. For instance, in an environment where a secretary may be available to take the call, a nursing coordinator can be used to enter “intake” or “telephone consultation” data. This allows the physician to then focus on medically- relevant data. The data entry forms that are to be used by a secretary can be customized separately to support non-medical terminology to assist with non-physician data entry of demographic and administrative information. This data is again shared bi-directionally to all users in that department so that when they go to see the patient for whom the consult was called, they can directly proceed with the patient evaluation.

A Language-Independent, Customizable Report System

Custom Reports can be generated “ad hoc” or from predefined templates, customized for each language, and supplied in standardized Microsoft™ Word format. While use of Word™ templates is perhaps not the most economical way to provide reports (instead of using a built-in Crystal Reports, or other reporting packages), the advantage is that Microsoft™ Word is supported in multiple languages, and users are intimately familiar with this form of documentation. For instance, if one chooses to edit the Word document from CISCL, they can add their hospital or personal logo and have it printed automatically with all reports. Translation of data sent to the report is performed intrinsically by the CISCL program. Similarly, if one chooses to use hospital or other custom stationary, one can simply edit the Word™ document to support this change. In addition, Word™ was found to be the most flexible mechanism to support complex Asian characters and extended character sets automatically.

Using Standardized Metrics for Psychiatric Care

There are many standard methods for evaluating the psychiatric patient. Many reliable scales for evaluation include the abbreviated Mini Mental State Examination (MMSE), Hamilton Depression score, Glasgow coma score, and Beck Depression or Anxiety Scale. Other standardized examinations are used routinely as part of hospital inpatient admissions. And many are repeated during therapy to ascertain whether the patient has made progress.

CISCL supports input of questionnaires such as these in multiple languages, and is particularly helpful at guiding the system administrator through creation of new scales for patient testing. These scales are inserted into the regional database with all the custom code group and language preferences. Since the code groups are defined in the regional language, the electronic exam automatically has access to the custom standards of that user and their department. As seen in the Mexican version of CISCL, the Escala de Experiencia Sexual de Arizona (ASEX) scale is one that was of particular use for the HE Centro Medico National, and it was added to their version of the database. This questionnaire is not found in English CISCL, but can easily be imported directly.

The nature of medical care is also changing. With automated systems, patients can be expected to enter data into an electronic questionnaire on their own. This can occur while the physician is engaged in other patient care tasks. Standardized test data can even be automatically collected via laptop in the waiting room or at the patient’s bedside under the guide of secretarial or nursing teams.

Regional versions of many standardized exams already exist. The important emphasis of the CISCL approach is that since the data is linked to a language-independent matrix, it is often extremely easy to directly compare survey data from multiple regions. For instance, the underlying coding scheme for the Mini Mental State Examination is the same whether it has been modified to support spelling “WORLD” or “MUNDO” backwards. Different language databases can have different collections of questionnaires or scales, but more importantly can continue to share data. Multi-center research can be performed across different institutions and different languages by creating custom survey that has been entered using the “Survey Wizard” module in CISCL (See below).

Language Manager

The CISCL program can be initiated in a “Developer Mode” where any text item on the GUI can identified and update via the “Language Manager.” As shown in the Figure 3, the cursor when held on the item on the screen will show the corresponding “resource key” and the language manager then allows the user to search and replace this with any description the user’s request.

The CISCL program can also dynamically change to another supported language via the Language Options menu. Why this is so useful is that Spanish-speaking users can examine the CISCL data from any other CISCL user in any of the other languages and compare their datasets directly. The linking of the data allows us also to merge multilanguage datasets for advanced comparison and analysis.

The language modifications can even be used to match the needs of country-specific, regional translation issues, such as modifying the Portuguese database for costal or mountain Portugal or Brazilian regional dialects.

Custom “Survey Wizard” Questionnaire Designer

The Survey Wizard is a unique CISCL tool of particular use to regional customization. One of the most useful and flexible features of Micro-CaresTM CISCL, it is a proprietary system which allows a user to efficiently generate a survey (or scale), create an individualized collection tool, and integrate and standardize the data entry across multiple data sources within the CISCL database.

Actually, this Wizard, due to its ability to provide flexible modeling and revision of underlying data structures, was used to create the main Psychiatric Consultation data entry form used by CISCL. Similarly, the Survey Wizard can be used for all of the following:

I. Create and review public domain and private surveys:

II. Modify existing surveys:

III. Create new surveys for outcomes tracking at the point of care.

IV. Create new surveys for the patient to enter data into while waiting for an appointment.

V. Create patient information data collection tools such as customized History and Physicals, Consultation Forms and Flow Sheets.

The Survey Wizard’s functionality is adaptable to native language needs by allowing direct access to “code groups” or even creation of temporary custom variables that can be accessed by any questionnaire. For instance, the cities or states can be stored in code groups for use by all portions of CISCL and are predefined. But how does such a system support complex data collection? For example, what if it is necessary to generate a new scale where Answer#1 is worth 10 points, Answer #2 is worth 15, Answer #3 is worth 25, etc. These re-usable data elements can be created for a current survey, edited for different languages, or even shared as data collections with new surveys or studies. These flexible data-structures help transform the efforts by the physician in collection and CISCL data entry into an opportunity for “ad hoc” clinical data analyses. The underlying master database acts a foundation with links directly to additional surveys. In this way, CISCL provides a significant platform for research and patient care optimization. In addition, sponsorship for regional studies can be obtained by implementing data collection for national, international, and disease-targeted research efforts such as depression in HIV.

Engineering Multi-Language Support for CISCL

Modelling psychiatry work-flow has been a twenty-year project where recent technological advances have allowed expansion of functionality to match the requirements of psychosomatic care. Initial attempts focused on collecting over 300 data items on all patients for all physicians [13]. Assumptions were made that a secretary or group of data entry assistants were available to enter consultation information into the computer system. As the CISCL program has undergone evolution into a multi-language supporting system, there have been major issues in adapting it to support cultural and language diversity.

Initially, all CISCL screens were designed specifically to handle the length of English text. As we quickly discovered, each language has different physical length requirements. For example, a general guideline in translating English applications into German dialects is that the German text is expected to be 25% longer [14]. This length characteristic is a phenomenon we have seen in translating CISCL into Portuguese and Spanish as well as other languages. All CISCL forms were adjusted to permit additional text length with added space to support these expectations.

Originally, automated translation systems such as Whipple Ware and SysTrans [15] were used to directly translate screens from English into Spanish. Early attempts with automated translation led to accurate translation in 87% of the general text [16]. Some of the difficulty involved translation of truncated text and deciphering anagrams. And while this created “Spanish-appearing” screens, the specific language conversion was only about 50% correct in our experience for medical/psychiatric content. This was due to the inability of such translators (language translation systems) to place emphasis or understand nuances of the psychiatric medical description. For example, automated translation protocols fail to understand that “pen” can be either a writing implement or a fenced-in yard for animals; it is impossible for current automated translators to interpret the context [17].

Secondarily, “screen shots” were obtained of each screen in the graphic user interface, and paperversions of these were sent to local psychiatrist experts for translation. This was extremely time consuming and made updating the CISCL system difficult since each change to the GUI had to be copied, sent, translated, and re-entered into the system. This often required multiple iterations, with creation of the complete functioning program, sending it to the testing physicians, and then having them relay further changes.

In an attempt to increase the speed of translation, we then tried obtaining a local human translator to aid the programmers, in addition to distant regional experts for support. As in the case of the Portuguese translation, a Harvard University language expert was used. But since it was impossible to find a regionallyknowledgeable, medically-trained, psychiatrically-trained, Portuguesespeaking expert, many of our translations were unacceptable. Overall, many iterations were required and this led to a frustrating, extended cycle to completion.

Next, we arranged for a regional expert to sit alongside the programmer and guide translation. This was extremely successful, but hugely resource expensive, and was only able to provide translation of the currently existing program. Additional features and continuous updates required waiting for periods when the psychiatrist experts and programmers were both available to provide translation. This translation process had to be repeated for every language, and every additional screen that was added. As we quickly discovered, translation efforts could not be generalized. For example, a Portugal Portuguese translation was not a substitution for a Brazilian version; each had to be modified for local acceptance.

Given the above difficulties, two new approaches were tested to provide flexibility to language translation: 1) “Resource Files” — upgradeable language files that could be quickly updated for each screen element, and 2) a custom language database built within each CISCL system. The resource file approach has been recently supported by Microsoft ™ Windows as a recognized standard for translation. It allows the user to compare “side-by-side” multiple languages and translate them accordingly. A “resource module” was added that allowed us to send to the regional expert a Microsoft Excel™ comparison file of the languages for translation. While this first approach, combined with e-mail, was more rapid than the use of “screenshots”, it continued to make adapting CISCL for regional language dialects (e.g., Mexico vs. Spain, etc.) extremely time-consuming and difficult to maintain. Also, updated resource modules had to be manually re-integrated into the CISCL program, and this required ongoing development time.

Our current model was developed based on limitations and difficulties experienced with the resource file approach. It provides a specialized “Language Editor” [Figure 3] which shows the user the current screen and the translation in any language of choice. Now the user can start with a routine language translation (e.g., Mexican Spanish), and modify any items on the screen, and any menus or messages that CISCL displays for the users, to provide regional, personal, and context-appropriate translation. This builds on previous language versions, and gives the user an unparalleled ability to create either a modified regional dialect, or even enter a completely new language with any of the character sets provided on their computer. It is our belief that this provides the most flexible option for medical users in diverse language and cultural environments.

Discussion

Suggestions for Multi-language Application Development

Support of Languages – Intelligent System Design

In the programming world, there are general approaches which support a multi-lingual model, but none of these are easy to implement or simple to maintain. Many new techniques have of necessity been proposed to support complex web-based and database applications. These are concurrently utilized in many countries, and three major architectures have become the most popular. They include Dynamic Content Generation, Site Replication, and Selective Replication [18,19]. As shown in Table 1, Dynamic Content Generation most closely approximates the schema utilized by CISCL. CISCL supports low-level access to all descriptors, and each is loaded dynamically as a language is called upon to be displayed. We performed extensive testing with our optimized language module and found essentially no performance differences with use of this approach over previous “resource” standards. An additional advantage is that we are able to automatically provide accurate translation for our web-based application, and also handheld information systems, since the multi-language data support files are directly accessible for all hardware systems connected to CISCL.

Based on the experience of many design teams who work for complex web-based and cell phonebased systems, there have been guidelines developed for optimizing computer applications for cultural diversity: 1) Identify target cultures you will be programming for, 2) Design and develop a global model that takes common designs into account, 3) Bring in a culture-specific interface designers and utilize local physicians to revise the design, and 4) conduct usability tests of culturally- targeted versions using regional subjects [21].

1. Targeting Cultures

In our experience, text language cannot be translated “word-for-word”. Comprehension of Western or English- based icons, symbols, clichés, slang, acronyms, and abbreviations may be difficult for local user groups. Local language and practice conventions need to be taken into account. Word wrapping and hyphenation need to be considered as well, since improper hyphenation of a word may change its meaning. And as described above, words written in one language differ in length from words in another language, and this must be taken into account in the interface design [20].

Each portion of the GUI must support the “regional settings” of the local user. Multiple numeric, currency, time, and distance formats can be manipulated by the underlying operating system. As an example, numeric formats differ in certain Scandinavian countries, where “123.123” is expressed as “123,123”. The first representation is treated as a number, and the second is treated a text because of the presence of the comma symbol, and causes a failure in data analysis.

Images and color form the “visual language of a culture” [21]. The developer must choose understandable images and pictures, and avoid taboos and offensive icons: Symbolism must be respected, as in using pictures of animals which can have different cultural importance. Colors as well have culturedependent meanings. The color red, for example, may be used to represent a warning or an error message, but in another culture it may be used to promote a positive experience. Generally colors in user interfaces are used for grouping, verifying, or distinguishing objects from one another, but the target users must be able to comprehend their importance [21].

2. Global Model

Psychiatry as yet does not have a global model. Ideally, an application can be designed to meet the needs of every international user. Even with multiple internationally users, and continuous updates based on user feedback, this is a difficult task. With the dual goals of a) capturing psychiatric data and b) achieving a better user experience, we have used the actual, retrieved data to determine what we should collect. Beginning with a complex, all-inclusive psychiatric dataset, multiple years of data on tens of thousands of patients was analyzed to create a core dataset that is applicable to a majority of psychiatric patients. An architecture based on the core data, with the ability to add additional items as necessary, appears to be an effective way to design a globally-applicable model. As seen in Figure 4, it does allow for capture of a diverse, cultural dataset even in non-European venues [22].

3. Interface Design using “Cultural Representatives”

Acknowledged regional psychiatry experts with fluent language abilities have been necessary at all phases of GUI development. Technically, these are referred to as “cultural representatives” [21] The use of psychiatric cultural representatives in testing is particularly critical because without them it is often impossible to anticipate the user’s reaction to a program. These experts benefit program development in many ways: 1) it involves potential real users, 2) it allows us to have them do real tasks, and 3) it allows us to track where errors occur or the programmer’s perceptions do not match the user’s needs [18].

4. Usability Testing

Ideally, every user would have the benefit of the programmer at their side, customizing the computer program to meet their needs. Workflow practices and situational language preferences in this fashion could be documented. Unfortunately, this is usually not possible. However, there are several established techniques that we have used to revise CISCL closer to what is acceptable for users at each locale.

In some cases, many hours have been spent with “cultural representative” experts to review language translation and GUI characteristics. In addition, helpful suggestions have been provided by users via e-mail “screen-shots” of where corrections/additions can be made. We have also traveled to local regions for psychiatric conferences (such as the Asociacion Psychiatria Mexicana in Mexico) where group sessions have given us insight into local practices, and the CISCL system has been adapted accordingly. Some research companies having language test groups utilize “usability diaries” to have their users log functional issues that they encounter. A newer technology has been the ability to remotely “login” to a user’s computer (with their permission) to track how they use the system and assist them in local/regional changes directly. We have been utilizing “GoToMeeting” as one of these technologies [23].

In summary, our current useraccessible resource definition has significant benefits. Built-in to CISCL, the “Language Manager” has special search modes to identify code or description, and dynamically changes the display screens, allowing trial of different words or anagrams, or even more descriptive truncated sentences. This information is supported separately in a communication layer which does not affect the underlying patient database architecture. New languages or dialects can also be quickly developed based on currently available language modules. And with this design, the user can edit the GUI concurrent with data entry, e.g. change the description of the demographic interface while performing data collection on patients.

Language descriptors are reusable for new programming, and as new features are added, the previously approved language code can be called upon for translation. A standardized protocol for addition of new codes means that with minimal work, a program can be updated for all languages currently supported. Overall, this approach speeds up the deployment cycle in that there is no more need for creating the GUI, then translating, then sending to programmers, then verifying that works, then creating a final “distribution version” for testing. CISCL provides concurrent use and language optimization, and is structured according to the principles which are believed to be essential to providing a good multicultural graphic user interface (see Table 2) [21].

Conclusions

Electronic Medical Record (EMR) systems cannot be converted to a regional language effectively without identification of a regional expert to assist in the translation. Early effort must be placed into identifying regional customs and practice standards.

Multiple iterations of translation will need to be undertaken because adaptation may require use of idioms, anagrams, or custom truncation of definitions/descriptions.

A method must be provided with continuous editing of the program at the “local” level – generation of user “language dictionaries.”

Link to universal standards (e.g., International Classification of Disease [ICD], Current Procedural Terminology [CPT], Diagnostic and Statistical Manual of Mental Disorders [DSM IV], etc) with well-codified translations may assist in making a program more universally and regionally acceptable.

Ultimately, program customization and translation may even require a new graphic user interface, or use of a new technology platform, to be accepted.

Recibido para evaluación: 22 de abril de 2006 Aceptado para publicación: 2 de mayo de 2006