---
{
  "title": "Designing Multilingual Forms for Global Healthcare: One Form in Many Languages",
  "description": "Instead of duplicating a form for every language, define it once and extend it with translations and terminology bindings — one structured form that renders in many languages.",
  "date": "2026-05-21",
  "author": "Maria Ryzhikova",
  "reading-time": "5 min read",
  "tags": ["Forms", "Terminology"],
  "utm-campaign": "feature",
  "utm-content": "multilingual-forms"
}
---

## Introduction

Healthcare systems rarely operate in a single language.

In many parts of the world, this is not just a preference but a requirement. In countries like Switzerland, healthcare must function seamlessly across German, French, and Italian. In Canada, both English and French are used in clinical and administrative contexts. In India, applications often need to support multiple regional languages alongside English, while in South Africa, healthcare systems operate in an environment with more than ten official languages. Even in regions that appear more linguistically uniform, multilingual needs quickly emerge when digital health products expand across borders or serve diverse patient populations.

And yet, when it comes to forms, the most common solution is still surprisingly inefficient: create the same form multiple times — one per language.

At first glance, this approach seems straightforward. But as soon as forms evolve — new fields are added, logic is updated, validation rules change — the cost of duplication becomes obvious. Each version must be maintained separately, translations drift over time, and inconsistencies begin to appear.

What starts as a simple workaround quickly turns into a maintenance problem.

## The Problem with Duplicated Forms

A typical multilingual setup relies on maintaining separate versions of the same form for each language. While this may work initially, it introduces structural fragmentation.

Each form version becomes its own entity. Logic may evolve differently, validation rules may diverge, and updates may be applied inconsistently. Over time, forms that are supposed to represent the same data model no longer behave the same way.

This is not just a UX issue — it directly affects data quality.

When forms are duplicated, the structure behind them is duplicated as well. In systems that rely on structured data, such as FHIR-based architectures, this creates inconsistencies that are difficult to reconcile later. Data collected through different language versions may no longer align cleanly, making aggregation, analytics, and interoperability more complex.

## A Better Approach: One Form, Multiple Languages

A more scalable approach is to define the form once and extend it with translations.

Instead of creating multiple forms, a single form definition becomes the source of truth. All languages are added as part of this definition, typically through extensions.

This introduces a critical separation between structure and presentation. The structure of the form remains stable, while the presentation layer adapts to the user's language. Every question, label, and instruction can have multiple language representations, but they all point to the same underlying data model. The logic, validation, and mappings remain consistent across all languages.

In FHIR Questionnaires, translations are attached to each element using the standard `translation` extension. A single question carries its default text plus one entry per language:

```json
{
  "linkId": "chief-complaint",
  "type": "string",
  "text": "Chief complaint",
  "_text": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/translation",
        "extension": [
          { "url": "lang", "valueCode": "de" },
          { "url": "content", "valueString": "Hauptbeschwerde" }
        ]
      },
      {
        "url": "http://hl7.org/fhir/StructureDefinition/translation",
        "extension": [
          { "url": "lang", "valueCode": "fr" },
          { "url": "content", "valueString": "Motif de consultation" }
        ]
      }
    ]
  }
}
```

This approach eliminates duplication and ensures that all users, regardless of language, interact with the same form structure.

## How Multilingual Forms Work in Practice

A multilingual form typically has a default language and a set of translations attached to each element. When the form is rendered, the system determines which language to display. This can happen in two main ways.

In some cases, the form is launched directly in a predefined language. This is common when the application already knows the user's language preference — for example, from profile settings or system configuration.

In other cases, users can switch languages during form completion. This is particularly useful in real-world clinical scenarios, where a clinician and a patient may not share the same language. A clinician may start filling out a form in one language and switch to another to confirm information with the patient.

In both cases, the underlying form remains unchanged. Only the visible text is updated.

## The Role of Terminology and Value Sets

Multilingual support is not only about translating labels. It is also about ensuring that answer options are correctly localized while preserving their meaning.

This is where terminology binding and value sets become essential.

When answer options are defined using standardized codes — such as SNOMED CT or LOINC — the system can retrieve the appropriate display values in different languages. The same coded concept can be presented differently depending on the selected language, while still representing the same underlying meaning.

This creates a clear separation between what the user sees and what the system stores. Users interact with familiar, localized text, while the system works with stable, coded values. This ensures that data remains consistent, interoperable, and suitable for analytics, regardless of language.

In practice, when a form is rendered, the current language — either the default language or the language selected by the user — is passed to the `displayLanguage` parameter of the `ValueSet/$expand` operation:

```http
GET /fhir/ValueSet/$expand?url=http://example.org/fhir/ValueSet/symptoms&displayLanguage=fr
```

The terminology server uses this parameter to search for the appropriate translations and returns the value set in the requested language. If a translation for a specific concept is not available, the terminology server falls back to the default language.

This mechanism allows multilingual forms to dynamically display localized answer options while preserving the same underlying coded structure across all languages. Without this layer, multilingual forms risk becoming fragmented again — not at the data structure level, but at the semantic level.

## What Happens When the Form Is Submitted

Language also plays a role at the moment of submission.

The user interacts with the form in a selected language, and this context is reflected in the response. The saved response corresponds to the language used at the moment of completion.

At the same time, the structured data behind the response remains stable. Codes, mappings, and extracted data do not depend on the language of the interface.

This allows systems to preserve both:

- the user-facing representation of the data
- the standardized structure required for interoperability

As a result, data remains both human-readable and machine-readable.

## Why This Matters for Modern Healthcare Applications

Multilingual forms are not just a convenience feature. They are a requirement for modern healthcare systems.

Applications today are rarely confined to a single region or language. They must support diverse user groups, cross-border workflows, and global deployments.

In the context of interoperability initiatives like EHDS, this becomes even more critical. Data must move across countries and be understood across systems, regardless of the language in which it was captured.

By separating structure from presentation, multilingual forms enable this. They allow users to interact with data in their own language, while ensuring that the data itself remains consistent, standardized, and reusable.

## Conclusion

The traditional approach to multilingual forms — duplicating forms for each language — does not scale and introduces unnecessary complexity.

A more effective model is to define the form once and extend it with translations. By combining a single structured form definition with translation extensions and terminology-based value sets, it is possible to create forms that are both user-friendly and interoperable.

This approach reduces maintenance overhead, improves consistency, and aligns with modern standards such as FHIR.

In a connected healthcare ecosystem, multilingual support is not an additional feature. It is a fundamental capability. And when implemented correctly, it does not complicate forms — it makes them simpler, more robust, and ready for real-world use.

To see how multilingual forms work in practice, watch a short demo:

{% embed url="https://www.youtube.com/watch?v=uuCK40tfEGo" %}

Or start building and testing your own multilingual forms in the [Aidbox Form Builder](https://form-builder.aidbox.app/?utm_source=health-samurai-blog&utm_medium=article&utm_campaign=multilingual-forms&utm_content=form-builder-cta#).