---
{
  "title": "Mehrsprachige Formulare für das globale Gesundheitswesen: Ein Formular in vielen Sprachen",
  "description": "Statt ein Formular für jede Sprache zu duplizieren, definieren Sie es einmal und erweitern es um Übersetzungen und Terminologiebindungen – ein strukturiertes Formular, das in vielen Sprachen dargestellt wird.",
  "date": "2026-05-21",
  "author": "Maria Ryzhikova",
  "reading-time": "5 min read",
  "tags": ["Forms", "Terminology"],
  "utm-campaign": "feature",
  "utm-content": "multilingual-forms"
}
---

## Einleitung

Gesundheitssysteme arbeiten selten in einer einzigen Sprache.

In vielen Teilen der Welt ist dies nicht nur eine Präferenz, sondern eine Anforderung. In Ländern wie der Schweiz muss das Gesundheitswesen nahtlos auf Deutsch, Französisch und Italienisch funktionieren. In Kanada werden sowohl Englisch als auch Französisch in klinischen und administrativen Kontexten verwendet. In Indien müssen Anwendungen häufig mehrere Regionalsprachen neben Englisch unterstützen, während in Südafrika Gesundheitssysteme in einem Umfeld mit mehr als zehn Amtssprachen operieren. Selbst in Regionen, die sprachlich einheitlicher erscheinen, entstehen mehrsprachige Anforderungen schnell, sobald digitale Gesundheitsprodukte über Grenzen hinweg expandieren oder vielfältige Patientengruppen versorgen.

Und dennoch ist die gängigste Lösung bei Formularen nach wie vor überraschend ineffizient: dasselbe Formular mehrfach erstellen – eines pro Sprache.

Auf den ersten Blick erscheint dieser Ansatz unkompliziert. Sobald sich Formulare jedoch weiterentwickeln – neue Felder hinzukommen, Logik aktualisiert wird, Validierungsregeln sich ändern – werden die Kosten der Duplizierung offensichtlich. Jede Version muss separat gepflegt werden, Übersetzungen driften im Laufe der Zeit auseinander, und Inkonsistenzen beginnen sich einzuschleichen.

Was als einfache Übergangslösung beginnt, wird schnell zu einem Wartungsproblem.

## Das Problem mit duplizierten Formularen

Ein typisches mehrsprachiges Setup basiert auf der Pflege separater Versionen desselben Formulars für jede Sprache. Während dies anfangs funktionieren mag, führt es zu struktureller Fragmentierung.

Jede Formularversion wird zu einer eigenständigen Entität. Die Logik kann sich unterschiedlich entwickeln, Validierungsregeln können auseinanderdriften, und Aktualisierungen werden möglicherweise inkonsistent angewendet. Im Laufe der Zeit verhalten sich Formulare, die dasselbe Datenmodell repräsentieren sollen, nicht mehr gleich.

Dies ist nicht nur ein UX-Problem – es wirkt sich direkt auf die Datenqualität aus.

Wenn Formulare dupliziert werden, wird auch die dahinterliegende Struktur dupliziert. In Systemen, die auf strukturierten Daten beruhen, wie beispielsweise FHIR-basierten Architekturen, entstehen dadurch Inkonsistenzen, die später nur schwer zu bereinigen sind. Daten, die über verschiedene Sprachversionen erfasst wurden, lassen sich möglicherweise nicht mehr sauber zusammenführen, was Aggregation, Analysen und Interoperabilität erschwert.

## Ein besserer Ansatz: Ein Formular, mehrere Sprachen

Ein skalierbarerer Ansatz besteht darin, das Formular einmal zu definieren und es um Übersetzungen zu erweitern.

Anstatt mehrere Formulare zu erstellen, wird eine einzige Formulardefinition zur zentralen Datenquelle. Alle Sprachen werden als Teil dieser Definition hinzugefügt, typischerweise über Erweiterungen.

Dies führt eine wichtige Trennung zwischen Struktur und Darstellung ein. Die Struktur des Formulars bleibt stabil, während sich die Präsentationsschicht an die Sprache des Benutzers anpasst. Jede Frage, jede Beschriftung und jede Anweisung kann mehrere sprachliche Darstellungen haben, sie verweisen jedoch alle auf dasselbe zugrundeliegende Datenmodell. Logik, Validierung und Mappings bleiben über alle Sprachen hinweg konsistent.

In FHIR Questionnaires werden Übersetzungen mithilfe der standardmäßigen `translation`-Erweiterung an jedes Element angehängt. Eine einzelne Frage enthält ihren Standardtext sowie einen Eintrag pro Sprache:

```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" }
        ]
      }
    ]
  }
}
```

Dieser Ansatz eliminiert Duplizierungen und stellt sicher, dass alle Benutzer unabhängig von ihrer Sprache mit derselben Formularstruktur interagieren.

## Wie mehrsprachige Formulare in der Praxis funktionieren

Ein mehrsprachiges Formular hat typischerweise eine Standardsprache und einen Satz von Übersetzungen, die an jedes Element angehängt sind. Bei der Darstellung des Formulars bestimmt das System, welche Sprache angezeigt werden soll. Dies kann auf zwei Arten geschehen.

In manchen Fällen wird das Formular direkt in einer vordefinierten Sprache aufgerufen. Dies ist üblich, wenn die Anwendung die Sprachpräferenz des Benutzers bereits kennt – beispielsweise aus den Profileinstellungen oder der Systemkonfiguration.

In anderen Fällen können Benutzer während der Formularausfüllung die Sprache wechseln. Dies ist besonders nützlich in realen klinischen Szenarien, in denen ein Kliniker und ein Patient möglicherweise nicht dieselbe Sprache sprechen. Ein Kliniker kann damit beginnen, ein Formular in einer Sprache auszufüllen, und dann zu einer anderen wechseln, um Informationen mit dem Patienten zu bestätigen.

In beiden Fällen bleibt das zugrundeliegende Formular unverändert. Nur der sichtbare Text wird aktualisiert.

## Die Rolle von Terminology und Value Sets

Mehrsprachige Unterstützung betrifft nicht nur die Übersetzung von Beschriftungen. Es geht auch darum sicherzustellen, dass Antwortoptionen korrekt lokalisiert werden, während ihre Bedeutung erhalten bleibt.

Hier werden Terminologiebindungen und Value Sets unverzichtbar.

Wenn Antwortoptionen mit standardisierten Codes definiert werden – beispielsweise SNOMED CT oder LOINC – kann das System die entsprechenden Anzeigewerte in verschiedenen Sprachen abrufen. Dasselbe kodierte Konzept kann je nach ausgewählter Sprache unterschiedlich dargestellt werden, repräsentiert jedoch weiterhin dieselbe zugrundeliegende Bedeutung.

Dies schafft eine klare Trennung zwischen dem, was der Benutzer sieht, und dem, was das System speichert. Benutzer interagieren mit vertrautem, lokalisiertem Text, während das System mit stabilen, codierten Werten arbeitet. Dies stellt sicher, dass die Daten unabhängig von der Sprache konsistent, interoperabel und für Analysen geeignet bleiben.

In der Praxis wird beim Rendern eines Formulars die aktuelle Sprache – entweder die Standardsprache oder die vom Benutzer ausgewählte Sprache – an den Parameter `displayLanguage` der Operation `ValueSet/$expand` übergeben:

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

Der Terminologieserver verwendet diesen Parameter, um nach geeigneten Übersetzungen zu suchen, und gibt das Value Set in der angeforderten Sprache zurück. Wenn eine Übersetzung für ein bestimmtes Konzept nicht verfügbar ist, fällt der Terminologieserver auf die Standardsprache zurück.

Dieser Mechanismus ermöglicht es mehrsprachigen Formularen, lokalisierte Antwortoptionen dynamisch anzuzeigen, während dieselbe zugrundeliegende codierte Struktur über alle Sprachen hinweg erhalten bleibt. Ohne diese Schicht laufen mehrsprachige Formulare Gefahr, erneut fragmentiert zu werden – nicht auf der Datenstrukturebene, sondern auf der semantischen Ebene.

## Was passiert, wenn das Formular übermittelt wird

Die Sprache spielt auch zum Zeitpunkt der Übermittlung eine Rolle.

Der Benutzer interagiert mit dem Formular in einer ausgewählten Sprache, und dieser Kontext spiegelt sich in der Antwort wider. Die gespeicherte Antwort entspricht der Sprache, die zum Zeitpunkt der Ausfüllung verwendet wurde.

Gleichzeitig bleibt die strukturierten Daten hinter der Antwort stabil. Codes, Mappings und extrahierte Daten sind nicht von der Sprache der Benutzeroberfläche abhängig.

Dies ermöglicht es Systemen, beides zu bewahren:

- die benutzerseitige Darstellung der Daten
- die standardisierte Struktur, die für Interoperabilität erforderlich ist

Dadurch bleiben die Daten sowohl für Menschen als auch für Maschinen lesbar.

## Warum dies für moderne Gesundheitsanwendungen wichtig ist

Mehrsprachige Formulare sind keine bloße Komfortfunktion. Sie sind eine Anforderung für moderne Gesundheitssysteme.

Anwendungen sind heute selten auf eine einzige Region oder Sprache beschränkt. Sie müssen vielfältige Benutzergruppen, grenzüberschreitende Workflows und globale Einsatzszenarien unterstützen.

Im Kontext von Interoperabilitätsinitiativen wie EHDS wird dies noch kritischer. Daten müssen über Ländergrenzen hinweg weitergegeben und systemübergreifend verstanden werden, unabhängig von der Sprache, in der sie erfasst wurden.

Durch die Trennung von Struktur und Darstellung ermöglichen mehrsprachige Formulare genau dies. Sie erlauben es Benutzern, in ihrer eigenen Sprache mit Daten zu interagieren, während sichergestellt wird, dass die Daten selbst konsistent, standardisiert und wiederverwendbar bleiben.

## Fazit

Der traditionelle Ansatz für mehrsprachige Formulare – das Duplizieren von Formularen für jede Sprache – ist nicht skalierbar und führt zu unnötiger Komplexität.

Ein effektiveres Modell besteht darin, das Formular einmal zu definieren und es um Übersetzungen zu erweitern. Durch die Kombination einer einzigen strukturierten Formulardefinition mit Übersetzungserweiterungen und terminologiebasierten Value Sets ist es möglich, Formulare zu erstellen, die sowohl benutzerfreundlich als auch interoperabel sind.

Dieser Ansatz reduziert den Wartungsaufwand, verbessert die Konsistenz und entspricht modernen Standards wie FHIR.

In einem vernetzten Gesundheitsökosystem ist mehrsprachige Unterstützung keine zusätzliche Funktion. Sie ist eine grundlegende Fähigkeit. Und wenn sie korrekt implementiert wird, macht sie Formulare nicht komplizierter – sie macht sie einfacher, robuster und bereit für den realen Einsatz.

Um zu sehen, wie mehrsprachige Formulare in der Praxis funktionieren, schauen Sie sich eine kurze Demo an:

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

Oder beginnen Sie, Ihre eigenen mehrsprachigen Formulare im [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#) zu erstellen und zu testen.