Risk-Based Validation of Multilingual Device Software

The globalization of the medical device marketplace, combined with the growth of device software, has led to a significant increase in software localization activity among device manufacturers (see sidebar for more on software localization). Though not yet a universal regulatory requirement, software localization has become an important competitive tool to gain access to foreign markets. As clinicians, patients, regulators, and litigators become more sensitive to safety issues related to human factors, the importance of appropriate translation and localization controls will increase. 

     Since localization can add technical and linguistic complexities to the software development process, appropriate risk management is necessary to ensure device usability, safety, and regulatory compliance.  

     In some cases, critical human factors and risk management decisions are made that depend on specific language in the user interface or labeling. For instance, hazardous situations can arise based on improper interpretation of date/time information or units of measurement displayed. Mitigation of such risks is typically a key focus during initial device development for the initial locale (e.g., the United States); however, the impact of translation and localization on these items is often not as carefully identified, controlled, verified, and validated.  

Regulatory Background 

According to the Federal Food, Drug, and Cosmetic (FD&C) Act, software that meets the definition of a medical device is considered a medical device and is therefore subject to all applicable FDA medical device regulatory provisions. Specifically, 21 CFR 820.30 requires design control, including verification and validation activities. These activities are intended to be performed throughout the entire software life cycle at a level of effort commensurate with the device risk and the intended use of the software. Labeling (whether paper or electronic) is considered part of the device and is therefore also subject to design control.

     When distributing medical devices with software in European Union (EU) markets, these devices become subject to the general and essential requirements of the relevant EU directives, such as the Medical Device Directive (MDD), In Vitro Diagnostic Medical Device Directive (IVDD), or Active Implantable Medical Devices (AIMD). The MDD considers medical devices “… any instrument, apparatus, appliance, material or other article, whether used alone or in combination, including the software necessary for its proper application intended by the manufacturer to be used for human beings for the purpose of …” 

     In addition, ISO 13485:2003 requires design control and software validation similar to FDA Quality System Regulation Part 820.30. 

The Challenges 

Although localization of medical device software is currently not an across-the-board requirement, it can be an important tool to mitigate residual product risk, gain advantage in foreign markets, and support a global user base. Much like the translation of labeling, software localization adds unique challenges and risks to the design and development process. 

     Similar to labeling and document translation, software localization can be part of the original software development requirements and specifications, or it can constitute a modification (“change”) to an existing software version. In either case, based on applicable standards and requirements for medical devices, software development (including any localization effort) should be subject to the same risk management and validation requirements as other design and development activities. 

The User Interface 

Like product labeling, software user interface (UI) components can carry important information for the safe and effective use of the device. However, in contrast to labeling, the software UI also provides the medium for the user’s interaction with the device (in some cases, the software is the only way to interact with the device, or, as with stand-alone software, the software itself is the device). Through inputs and outputs (navigation controls, forms, etc.) and feedback on actions and events (e.g., prompts or error messages), the UI provides the user with the means to directly control the functionality of the device. 

     The critical importance of software UI integrity requires comprehensive testing, verification, and validation of UI elements to ensure error-free operation. However, in addition to functional requirements, usability factors can significantly contribute to the risk of use error. 

     FDA’s recent Human Factors Initiative has underscored the importance of applying human factors knowledge and techniques to product design with the goal of minimizing the risk of use errors. Localization adds two key variables to the human-computer interaction that can have significant impact on usability: language and locale (e.g., unit of measurements and other conventions). 

Approaches and Processes 

Based on the potential impact localization can have on device usability and clinical risk, localization requirements should be included in the software design specifications, risk management plan, and validation procedures. Key areas of consideration are:  

• Localization risk analysis: What can go wrong?

• Internationalization needs assessment: Is my software ready to be localized?

• Localization testing, verification, and validation: How much validation is needed?

• Security: How are language or other configuration files secured sothey can only be modified by the device manufacturer? 

Implementing Localization Controls 

To minimize error risk introduced by the localization process itself, appropriate process controls, resource controls, and verification steps must be in place for all localization activities, including linguistic processes, engineering tasks, testing procedures, and configuration management. 

     For instance, an effective verification method for successful internationalization can include Localization Pre-Flighting, a simulation of the localization process that takes place prior to any localization activity. This step helps uncover and address potential issues, such as character set and font incompatibilities, string length restrictions, unit and data format conversion, or problematic string concatenation (see sidebar at left).         

     An effective linguistic quality assurance process should be in place that incorporates appropriate translation risk management. For instance, a linguistic review of software components prior to any translation activity can identify specific areas of linguistic risk and help pre-empt translation errors from the outset. Common issues encountered in this step are lack of space for language expansion and error-prone string concatenation. Ideally, this review is part of the internationalization process to improve localizability of the content. 

     Translations should be produced by professional, subject- specialized translators who are native speakers of the target language and experts in translation for software localization. Appropriate reference materials (instructions for use or other documentation), as well as knowledge of the device and its intended use, are key in producing accurate, context-sensitive translations of software strings. In addition, terminology management through glossaries and lexicons will ensure consistency between user documentation and software user interface components. Where relevant local or international standards exist that specify terminology (such as for warning and alarms) those doing translations or involved in verifying the translations must be aware of specific requirements. 

Choosing a Validation Strategy 

Even when appropriate process and resource controls for localization are in place, regulatory provisions and directives require that medical device software be validated for its intended use, and localized software is not exempt from this requirement. In fact, since localization is the complete modification of the device user interface content—the very element that the user employs to control the device—the impact on functionality and usability can be significant. 

     Determining the most appropriate scope and rigor for the localization validation—just like the overall software validation—is not always an easy task. How much validation is necessary? Who should validate, and when? How much evidence should be created and maintained? 

     The validation process applied to the localized device should be based on a comprehensive risk assessment that takes into consideration device risk, localization risk (technical and linguistic), and use risk. Ideally, the device risk analysis would identify specific aspects of the user interface and labeling that are risk related and warrant extra care as well as differentiating the level of risk between different portions of the user interface and associated labeling. For instance, a drug delivery device such as an infusion pump would carry a higher overall risk then a pregnancy test. Or, on a particular device, the screens for entering the dosage and displaying alarms would have more localization risk then other screens. Knowledge of these risks can enable a more efficient localization validation process by allowing less rigor for areas of lower risk and enforcing more rigor for higher risk aspects. 

     For many low- to moderate-risk devices, or lower risk portions of a device, a typical validation scenario may include the following processes and resources: 

• Development of validation protocol for testing of the software for all intended use cases.

• Verification of localized software screens by linguistic quality assurance professionals through side-by-side comparison against originals.

• Selection of one or more qualified validators for each target language; validators could be medical specialized linguists approved and controlled through ISO 13485 certified processes who are selected based on their familiarity with the product or technology.

• Training of validators in the use of the software, carried out technical/clinical staff with expert knowledge of the device.

• Validation of each language version as a standalone device and in accordance with validation protocol.

• Completion of a questionnaire with validation results and usability comments.

• Review of results and determination of required corrective action. 

     For higher risk devices, or higher risk portions of a device, additional validation processes or resources may be considered appropriate to further mitigate risk. For instance, certain devices may require validation through in-country clinical practitioners with familiarity in the use of the device type, or a representative cross-section of users for home use devices. Such a practitioner- conducted validation can be further expanded into a comprehensive in-country usability study with representative users in the relevant locale (with additional emphasis for home use or high risk devices). This type of validation scenario can also be of high value for evaluation of human factors/use errors that can lead to field incidents in one country to determine if localization changes are needed in other countries to prevent similar incidents. 

     Representative localization validation techniques are listed below in order of decreasing rigor:  

• In-country usability validation with representative users.

• In-country expert validation: Full functional and usability validation testing by a qualified practitioner in the target country.

• Expert assisted linguistic validation: Linguists conduct validation protocol under supervision of device expert.

• Linguist validation: Expert trained linguists carry out validation remotely on device or device emulator.

• Linguist validation: Linguists review documentation, install software, and conduct self-guided validation. 

     The higher the risks that the localization effort presents, the greater the necessary rigor. The techniques mentioned are not mutually exclusive and various combinations might be employed, depending on the type of device, its risks, and the nature of the user interface. 

     For many devices, the most practicable approach is to define the techniques to be used based on the overall risk of the device. However, for devices with more extensive UI and labeling, a more efficient approach can be to identify specific aspects of the localization/user interface that are risk/safety related and apply more rigorous techniques to the riskier areas and less rigor to less risky areas. In any event, it is important for the localization expert to understand what is risk related and what is not, so they can ensure adequate validation coverage and depth. 

Medical Device Risk Analysis Input to Localization 

To make the localization effort as effective and efficient as possible, it is critical for device user interface designers to consider localization and provide relevant risk analysis information. Some examples of integration of localization risk to the overall medical device risk management process are described below. 

     ISO 14971: Medical Device Risk Management identifies key elements of a risk management process. One aspect is identification of potential device hazards and causes that could contribute to hazardous situations. Some ways to address localization within an ISO 14971 context include: 

  1. Require localization to be considered as a possible cause for hazards (this will also lead to identification of appropriate risk control measures).
  2. Obtain localization risk input from localization expert for both labeling and UI strings.
  3. Provide UI-related risk analysis information to the localization and associated validation activities.

     ISO 62304: Medical device software – Software lifecycle processes requires that each software component be classified into one of three safety classes: 

  1. No injury or damage to health possible
  2. Non-serious injury possible
  3. Death or serious injury possible

     Based on the safety class of each software component, different minimum process requirements are indicated. Where practicable, this approach could be extended to portions of the user interface and associated data elements with potential localization impact (e.g., date/time, units of measurement, etc.). Specifically, portions of labeling and screens could be categorized into each of these three classes and the localization techniques required for each class could be pre-defined. This has the potential for ensuring not only the effectiveness but also the efficiency of the localization and its associated validation activities. 

Conclusion 

As the automation and complexity of medical devices increases, attention to good human factors design (in the device and its labeling) becomes more critical from a variety of perspectives, including quality, safety, legal, and regulatory perspectives. Where adequate emphasis on human factors occurs during development and validation for the initial country of distribution, localization for other countries is often done with insufficient rigor and control. In order to ensure appropriate risk management in this area, careful planning of the approach to localization and integration into the medical device risk management and validation processes are necessary to maximize the quality of the localized device and minimize safety risks. A truly risk-based approach will require effective two-way communication between device manufacturer and localization expert to ensure that all relevant risks are fully understood and addressed. Internationalization and localization risk information should be available as a design input at the early stages of the software device development cycle to facilitate appropriate planning of processes and resources for localization and validation. The localization expert will rely on input from relevant device risk/hazard information to apply the appropriate level of risk management to the localization process. Where practicable, risk management information can be used to make the localization and validation process more efficient by matching areas of higher risk with the most rigorous validation activity. 

     When taken into consideration in the device design and development cycle, localization validation can play an important role in ensuring the safety, compliance, and success of the device in the global marketplace. 

Kai Simonsen is the vice president of production and quality systems at the Crimson Life Sciences division of TransPerfect Translations. Simonsen has been responsible for the development and implementation of Crimson’s quality systems and risk management processes, including the world’s only translation quality system certified to ISO 13485:2003. 

Alan Kusinitz is managing partner of SoftwareCPR® and provides a software regulatory and safety information service and consulting at www.softwarecpr.com.

 

 

Crimson Life Sciences has become
TransPerfect Medical Device Solutions.


You will be redirected to the TransPerfect website in