How to translate and validate voice commands for a medical device

Translating and validating voice commands for a medical device is about more than simply replacing words in a list. A translated command must remain understandable to the user, consistent with the interface and recognised by the voice recognition engine. Above all, it must trigger the expected action without creating confusion that could affect safety.

The process brings together specialist translation, software localisation, voice engineering, risk management and usability testing. Validation should cover not only the text, but also pronunciation, accepted variants, acoustic conditions and how the device responds after each command is spoken.

Why should translated voice commands be validated?

A voice command is a functional element of the user interface. A translation can be linguistically correct yet still fail if it is too long, hard to pronounce, too similar to another command or poorly suited to the recognition model for the target language. Conversely, wording that the software recognises accurately may still be ambiguous to a healthcare professional.

Under Regulation (EU) 2017/745 on medical devices, the information accompanying a device must be provided in the languages required by the Member States. It also governs safety, performance and risk management throughout the device’s entire life cycle.

ISO 14971:2019, published by the International Organization for Standardization, provides a risk management framework applicable to medical devices. IEC 62366-1, relating to usability engineering, complements this approach by addressing risks associated with use and the user interface. In this context, validation of a voice interface must demonstrate that the intended users can perform the required tasks under representative conditions.

What needs to be translated before validating voice commands

The translation of voice commands cannot be separated from the rest of the user experience. The scope includes the commands spoken by the user, accepted synonyms, the wake word, audio confirmations, error messages, on-screen instructions and information in the instructions for use. A medical device translation service must therefore cover visible, audible and functional content.

It is also important to verify consistency between the different channels. If the screen displays “Stop the infusion”, the instructions for use say “Interrupt administration” and the engine expects “Stop infusion”, the user must memorise multiple formulations for the same action. This discrepancy increases cognitive load and can result in errors.

Translation and validation of medical device voice commands: a nine-step approach

The process should remain proportionate to the risk. A command that displays a help screen does not require the same level of control as one that changes a flow rate, initiates energy delivery or confirms an irreversible action. Acceptance criteria should therefore be defined for each command category.

1. Define the intended use and users

Define the user profiles, their level of training, the languages and regional variants, as well as the environments of use.

2. Classify commands according to their level of criticality

Classify voice commands and their corresponding actions according to their potential impact.

3. Analyse linguistic and acoustic risks

Look for homophones, similar phrases, negatives, numbers, units, abbreviations and words that may be masked by background noise.

4. Establish controlled terminology

The glossary should cover the device’s components, parameters, actions and states.

5. Adapt the translation for spoken use

The translation should prioritise natural, concise wording that is clearly distinct from other commands. It may be necessary to move away from a literal translation to preserve safety and recognition.

6. Integrate the language into the voice engine

The validated strings must be integrated into the voice engine, together with their variants, grammar rules, pronunciations, confidence thresholds and system responses.

7. Perform linguistic quality checks in context

The linguist checks the commands in the actual interface or a representative prototype.

8. Conduct acoustic and functional testing

Representative native speakers pronounce the commands under a range of conditions.

9. Validate usability and document the decision

The intended users perform the planned tasks in critical scenarios without guidance from the development team. The results, discrepancies, corrections and residual risks are recorded.

How can you develop an effective voice validation protocol?

An effective protocol does not test only a studio-recorded voice. It should cover the diversity of intended users and anticipated conditions, including regional accents, speech rates, wearing a mask and background alarms.

The test sets should also include negative cases, such as incomplete, ambiguous or unauthorised commands, or commands spoken out of context.

There is no universal threshold suitable for all devices. The criteria should be established before testing, justified by the risk analysis and made more stringent for the most critical actions.

How can you harmonise the interface language of a medical device?

The interface language of a medical device forms a system. Commands, menus, alarms, voice confirmations, instructions for use and training materials should use the same concepts. This consistency helps reduce the learning effort and facilitates incident analysis. It should also be maintained throughout the translation of the instructions for use associated with the product.

Before translation, it is useful to simplify the source text. Commands should be distinct, concise and predictable. Pairs such as “activate” and “deactivate”, or “increase” and “decrease”, require particular attention when spoken in noisy environments. Explicit confirmation may be required to ensure that a misrecognised syllable does not trigger the wrong action.

An archived Afssaps document on radiotherapy medical devices, published in 2007 and cited here as a historical illustration rather than as a current regulatory source, already linked the language and usability of the human-machine interface to risk management, operator profiles and training. For products deployed in multiple countries, the design should not be constrained by the syntax of the source language. The voice engine grammar, voice commands and screens must support the natural structures of each language.

Protect voice data and confidentiality

Voice constitutes personal data and may reveal information about the speaker or their environment, including the spoken content, certain characteristics of the speaker, their manner of speaking and the acoustic environment. When it is used to identify a person, additional requirements may apply to biometric data. The CNIL white paper on voice assistants emphasises transparency, security and privacy by design. The design should therefore define what data is collected, where it is processed, how long it is stored and who has access to it.

Local processing by the device can limit certain data transfers, but it does not eliminate all risks. Logs, audio files, transcripts, technical identifiers and test data must be inventoried and protected. The ANSSI (French National Agency for the Security of Information Systems) Guideline for a healthy information system in 42 measures recommends, among other things, identifying sensitive information and the components that host it in order to apply appropriate security measures.

Finally, the translation and validation protocol must govern the use of test recordings. The information provided to participants, access rights, retention periods, any transfers and file deletion must be defined. Voice engine and cloud service providers must be included in this mapping.

What evidence should be retained in the quality records?

Effective validation must be reproducible and auditable. The documentation should allow each command to be traced back to the relevant product requirement, associated risk, translation, software version and test results.

The records to be retained include the linguistic specifications, approved glossary, command matrix, test plan, participant profiles, description of the acoustic environments, raw results, anomalies, corrections and validation report. Acceptance criteria and decisions to grant exemptions must be explicitly justified.

Translation can be organised as part of a quality management system that meets the manufacturer’s requirements. ISO 13485 provides a framework for quality management for medical devices, while ISO 17100 sets out requirements for the processes and resources involved in translation services. These standards do not replace product testing, but they facilitate document control and the qualification of those involved. To explore this topic further, find out why it is essential to structure translation processes within the framework of the MDR and IVDR.

The most common errors to avoid

The following errors occur regularly:

• validating only the text, without testing speech;
• recording a single professional voice in a quiet environment;
• ignoring accents, masks and real-world noise;
• measuring average performance without analysing critical commands;
• omitting negative cases and unintended activations;
• translating the screen, voice and instructions for use separately;
• modifying a command without rerunning the relevant tests;
• using voice data without a clear confidentiality framework.

Frequently asked questions about voice command translation

Is a certified translation sufficient?

No. A certified or revised translation can demonstrate the linguistic quality of the content, but it does not prove that the engine correctly recognises users or that the device performs the correct action. Functional validation and, where justified by the level of risk, usability validation are still necessary.

Should each language be tested separately?

Yes, because length, phonetics, accents and ambiguities vary from one language to another. A result obtained in English cannot automatically be applied to French, German or Italian.

When should a new validation be carried out?

The need for a new validation should be assessed following any change that may affect recognition or use, such as a new translation, the addition of synonyms, a model update, a change of microphone, adjustment of thresholds, dialogue modification or a change in the intended use.

Conclusion

Successfully translating and validating voice commands for a medical device requires treating language as a component of its functionality and safety. The translation should be designed in conjunction with the interface, then verified in the voice engine, tested with representative users and documented using a risk-based approach.

By combining specialised translation, software localisation, acoustic testing and usability evaluation, the manufacturer can achieve a more consistent interface and stronger evidence. An experienced translation company specialising in medical devices can be involved from the outset, when commands are being defined, to avoid late-stage corrections and prepare a traceable multilingual protocol.