The European HealthTech Forum 2026, held in Alcobendas on 1 and 2 October, brought together hospitals, industry, start-ups and institutions from Europe and Latin America around one of the sector’s key challenges: how to move from innovation to adoption.
Healthcare technology has already demonstrated what it can do. The challenge now is to move solutions beyond the environment in which they were developed and make them viable across different hospitals, countries and healthcare systems.
Many factors influence this process, including clinical evidence, interoperability, funding, procurement, regulation, integration into clinical workflows and acceptance by healthcare professionals and patients.
There is, however, one factor that can easily go unnoticed until it is too late: language.
When a HealthTech solution is prepared for a new market, translating its content at the end of the development process is not enough. The product, documentation, terminology and, in some cases, clinical and regulatory materials all need to be adapted to the requirements and context of each market.
Localisation, therefore, should not begin when the product is finished. It should begin when the product is designed.
When the Pilot Works but the Launch Gets Stuck
The pattern is easy to imagine.
A digital health solution is successfully validated in a hospital. The results are positive, and the team decides to expand into new markets. Only then do previously overlooked issues emerge: interface text embedded in the code, alerts that no longer fit on screen in other languages, unvalidated clinical terminology or documentation that needs to be prepared for different regulatory requirements.
The problem is not that the product does not work. It is that it was designed for a single market.
Imagine a chronic disease monitoring app initially validated in Spain. The team decides to prepare for launch in Germany, France and Mexico, only to discover that part of the interface does not allow for text expansion, clinical alerts contain locally specific abbreviations and no one has defined which terminology should be used in each market.
Addressing these issues once the product is finalised may require code changes, interface redesign, content reviews and repeated testing.
What could have been resolved during the design phase becomes a timeline issue.
Late localisation also affects documentation. If the target markets are not defined early enough, teams may discover too late which documents need to be translated, which languages are required or which materials require specialist review.
Where Can Language Become a Barrier to HealthTech Adoption?
There are four areas where this risk is particularly significant.
-
Regulatory compliance: labelling, instructions for use and documentation
Language requirements form part of the EU regulatory framework for medical devices. Under the MDR, Member States may determine the languages in which certain information accompanying a device must be provided, meaning that manufacturers need to identify the applicable requirements for each target market.
This includes, among other things, information such as labelling and instructions for use.
The risk arises when these language requirements are identified only after the launch timeline has already been established. Translating, reviewing, typesetting and validating documentation at the last minute can create a bottleneck precisely when the product should be ready to enter the market.
This is why the market and documentation language map should form part of regulatory planning from the outset.
-
Product and software: interfaces, alerts and clinical messages
In healthcare software, language is not simply an interface layer. It is part of the product experience.
An alert, error message or instruction that loses clarity in translation can affect how a user interprets and interacts with the application.
A product that has not been designed with localisation in mind may also require development changes once the interface is already finalised: concatenated strings, insufficient space, text embedded in images or date and measurement formats that have not been adapted to the target market.
Internationalisation should therefore be considered from the beginning of development. Where possible, text should be kept separate from the code, sufficient space should be allowed for linguistic expansion, and clinical terminology should be managed centrally. Localisation should also include linguistic and visual testing in context, rather than relying solely on a review of translation files.
-
Clinical trials: when translation affects participant understanding
In clinical research, localisation has an additional dimension: participants need to understand the information they receive.
Regulation (EU) No 536/2014 establishes that information provided for the purposes of obtaining informed consent must enable participants to understand, among other things, the nature, objectives, benefits, implications and risks of the trial. It also requires the information to be clear, concise, relevant and understandable to a non-specialist.
This has direct implications for the translation and linguistic validation of informed consent forms, questionnaires and other participant-facing materials.
A translation may be linguistically accurate yet fail to achieve conceptual equivalence across languages. This is particularly important for instruments intended to measure patient-reported outcomes, where differences between language versions can affect comparability.
These materials therefore require a dedicated process and should not be treated as a last-minute task within the clinical trial timeline.
-
Europe and Latin America: one language does not necessarily mean one market
International expansion also raises a less obvious issue: sharing a language does not mean sharing a market.
Content developed for Spain will not necessarily work in Mexico, Colombia or Argentina. Clinical terminology, linguistic conventions, register, institutional references and user expectations can all differ.
This is particularly relevant for HealthTech companies looking to expand simultaneously across Europe and Latin America. Deciding which language variants are required before content development begins can prevent an apparently efficient solution—such as relying on a single form of “neutral Spanish”—from turning into multiple adaptations later.
AI and Human Validation: Accelerating Without Losing Control
Artificial intelligence is rapidly changing the way healthcare content is produced and localised. It can accelerate certain processes, facilitate terminology reuse and help manage large volumes of content.
But using AI effectively does not mean removing human involvement. The real question is where AI can add efficiency and what level of human oversight is required afterwards.
Within a professional language workflow, ISO 17100 sets requirements for translation and revision processes, while ISO 18587 sets requirements for the human post-editing of machine translation output. This makes it possible to design different workflows according to the content and its risk level.
Highly repetitive, lower-impact content may benefit from machine translation followed by professional post-editing. Clinical alerts, informed consent forms or certain regulatory documents may require a much higher level of review and control.
The question, therefore, should not be “AI or translator?”, but rather: What language process does each type of content require to achieve the necessary level of quality and control?
That decision should be made before the project begins and documented as part of the workflow.
How to Plan Localisation from the Product Design Stage
Effective localisation does not mean translating earlier. It means making the right decisions early enough to make effective localisation possible.
It is useful to distinguish between translation and localisation. Translation transfers content into another language. Localisation adapts the entire product—its interface, documentation, formats, terminology and user experience—to a specific market.
Planning should therefore begin at four key stages:
| Stage | What to prepare | What it prevents |
| Design | Keep text separate from the code, allow sufficient space for linguistic expansion and define clinical terminology | Redesigning screens or modifying code at the end |
| Development | Maintain up-to-date glossaries and translation memories and review language within the product | Content that is correct in a file but ambiguous in context |
| Regulatory planning | Map target markets, languages and required documentation for each country | Discovering language requirements once the timeline is already fixed |
| Clinical trials | Plan linguistic validation of patient-facing materials alongside the recruitment schedule | Delays caused by materials that have not yet been validated |
Three principles can help turn this planning into an operational process.
First, start with the market map. Before deciding which languages are needed, define where the solution is intended to be commercialised or deployed and in what order.
Second, treat terminology as a product asset. Clinical, technical and regulatory terms should not be reinvented for every project. They need an owner, an approval process and version control.
Third, allow time for validation. Localisation also requires review, testing and corrections. This time should be built into the project schedule from the outset, just as time is allocated to technical product testing.
What Should You Look for in a HealthTech Localisation Partner?
Choosing a provider based solely on price per word can prove particularly costly when problems emerge at a critical stage of the launch.
Before selecting a localisation partner, there are at least five areas worth checking:
- Current certifications. If the project requires processes in accordance with ISO 17100 or post-editing in accordance with ISO 18587, check the certifications, their scope and the issuing body.
- Specialist expertise. The technology being used is only part of the equation. It is important to know who translates, who reviews the content and what experience they have with medical, regulatory and clinical documentation.
- Regulatory and clinical trial experience. The provider should be able to demonstrate experience with the types of documentation the project actually requires.
- Traceability. The process should make it possible to identify who translated, reviewed and validated each piece of content and which version was used.
- Terminology management. Glossaries and translation memories should become reusable project assets and be maintained across versions and markets.
At Lexic, we have specialised in medical translation for the life sciences and healthcare sectors for more than 15 years. Our processes are certified to ISO 17100 and ISO 18587, and we apply the same principles of specialist expertise, traceability and quality control to multilingual translation and localisation projects.
Innovation Can Only Be Adopted If People Can Understand and Use It
The European HealthTech Forum highlighted one of the sector’s major challenges: moving from innovation to adoption. Its programme focused on issues including hospital adoption, scaling, funding and new models of care.
From a language perspective, the conclusion is straightforward: a solution is not truly ready to scale if language is left until the end.
Localisation involves much more than translating text. It can affect regulatory readiness, launch timelines, user experience, the understanding of clinical information and the ability to maintain a consistent product across different markets.
AI can accelerate this process, but it needs to be integrated into a controlled workflow, with clear criteria for what can be automated, what needs to be reviewed and who is responsible for final validation.
Internationalising a HealthTech solution starts long before the first file is sent for translation. It starts when the product is designed.
If you are preparing to expand a healthcare solution beyond its home market, the first step should not be to request a translation quote. It should be to define which markets, languages, documents and levels of validation the product will need to reach them successfully.
That roadmap can turn localisation into an integral part of the launch plan rather than the final obstacle standing between innovation and market adoption.
