Wenn es Ihnen wie mir geht, dann klingt Traceability vor allem eins: trocken. Als Programmierer und User Interface Designer liebe ich es, in die Gestaltung und Umsetzung abzutauchen.
Doch irgendwann kommt der Moment, an dem man erklären muss, warum das User Interface so gestaltet ist. Sei es einem kritisch fragenden Auditor, einem Stakeholder oder einem neuen Teammitglied.
Und Hand aufs Herz: Das ist im Nachhinein nicht immer leicht. Vor allem dann nicht, wenn sich der Gestaltungsprozess über längere Zeit hinzieht oder mehrere Personen gestalten. Dann grübelt man intensiv nach den Gründen, warum der Button dort platziert wurde – und wünscht sich, dass man das irgendwo notiert hätte.
Und genau da sind wir im Thema: Traceability ist eines dieser stillen Erfolgsgeheimnisse hinter gut gestalteten, sicheren und regulatorisch sauberen Medizinprodukten. Doch was ist Traceability eigentlich?
Traceability aus regulatorischer Sicht
ISO 13485
Beginnen wir mit der ISO 13485:2016, dem internationalen Standard für Qualitätsmanagementsysteme von Medizinprodukten, der in der EU – aber auch z.B. in der Schweiz und in Japan harmonisiert ist.
In Abschnitt 7.3.2 heißt es:
“The organization shall plan and control the design and development of product. As appropriate, design and development planning documents shall be maintained and updated as the design and development progresses. During design and development planning, the organization shall document:
[…]
e) the methods to ensure traceability of design and development outputs to design and development inputs;
[…]„
In anderen Worten: Für jeden Design- und Development-Output (z.B. eine Zeichnung, eine Spezifikation oder ein User Interface Screen) muss klar sein, auf welchen Design- und Development-Input (z.B. eine funktionale Anforderung, eine Anforderung aus dem Usability-Engineering, eine Ergebnis aus dem Risikomanagementprozess) er zurückzuführen ist.
Darüber hinaus fordert Abschnitt 7.3.6:
„Design and development verification shall be performed in accordance with planned and documented arrangements to ensure that the design and development outputs have met the design and development input requirements. […]„
Es wird also gefordert, dass mit einer Verifikation (und der entsprechenden Aufzeichnung darüber) nachgewiesen werden kann, dass ein Design- und Development-Output tatsächlich den Design- und Development-Input erfüllt bzw., dass das Gerät richtig gebaut wurde.
In Abschnitt 7.3.7 geht es dann weiter mit:
„Design and development validation shall be performed in accordance with planned and documented arrangements to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use. […]„
Hier wird die Validierung gefordert, die dokumentiert nachweist, dass das Gerät tatsächlich das tut, was es tun soll (intended use) – also ob das richtige Gerät gebaut wurde.
In der Praxis ergibt sich daher eine Art „Kreis“:
Der intended use bestimmt die Design- und Development-Inputs. Aus diesen Inputs entstehen die Design- und Development-Outputs. Die Outputs werden anschließend verifiziert, um zu zeigen, dass sie die Inputs erfüllen, und validiert, um sicherzustellen, dass das Produkt dem Intended Use gerecht wird.
US FDA Quality System Regulation (QSR) – und was sich mit der neuen Quality Management System Regulation (QMSR) ändert
Da die Vereinigten Staaten von Amerika für viele Medizinproduktehersteller ein wichtiger Markt sind, möchte ich an dieser Stelle auch auf die dort geltenden Regularien eingehen. Zum Zeitpunkt des Verfassens dieses Artikels gelten in den USA noch die Quality System Regulation (QSR, 21 CFR Part 820). Im Februar 2026 tritt nach einer zweijährigen Übergangsfrist die Quality Management System Regulation (QMSR) in Kraft.
Die neue QMSR wurde von der FDA mit dem Ziel entwickelt, die bisherigen Anforderungen an Qualitätsmanagementsysteme für Medizinprodukte mit der ISO 13485:2016 zu harmonisieren. Sie übernimmt die zentralen Prinzipien der ISO und verwendet weitgehend dieselbe Terminologie.
Daher gilt auch für die USA zukünftig das, was wir bereits im vorherigen Abschnitt zur ISO 13485 besprochen haben.
Aber auch die aktuell noch gültige QSR ist eng mit diesen Prinzipien verwandt. Sie basiert auf denselben Grundgedanken von Design Controls, also der nachvollziehbaren Verbindung zwischen Design Inputs, Design Outputs, Verification und Validation – und folgt damit der gleichen Traceability-Logik wie ISO 13485, nur in leicht anderer Sprache.
Wir verzichten an dieser Stelle auf einen detaillierten Blick in die noch gültige QSR. Wenn Sie sich tiefer einlesen möchten, dann finden Sie die Themen Design Input / Output sowie Verifikation und Validierung in 21 CFR 820 Subpart C.
Warum Traceability wichtig ist – weit über Compliance hinaus
Nachdem wir jetzt einen Überblick über die Regulatorik haben, lassen Sie uns noch mal auf die Eingangsfrage zurückkehren:
Löst Traceability denn jetzt das Problem, dass man Auditoren, Stakeholdern oder Kollegen erklären muss, warum zum Beispiel ein Button dort platziert ist, wo er platziert ist?
Die klare Antwort: nein – oder zumindest nur teilweise.
Lassen Sie mich erklären:
Keine der relevanten Normen – weder die besprochene ISO 13485 (Qualitätsmanagement), noch IEC 62366-1 (Usability), ISO 14971 (Risikomanagement) oder die erwähnte US-amerikanische QSR/QMSR – fordert, dass jede einzelne Designentscheidung dokumentiert wird.
Was sie aber sehr wohl verlangen, ist Nachvollziehbarkeit überall dort, wo eine Entscheidung Sicherheit, Leistung oder Gebrauchstauglichkeit beeinflusst.
Das bedeutet:
- Wenn eine Designentscheidung auf eine funktionale, sicherheitsrelevante oder regulatorische Anforderung zurückgeht, dann muss ihre Rationale dokumentiert sein.
- Wenn eine Designänderung eine Risiko-Minderung betrifft, muss die Verbindung zwischen Risiko, Maßnahme und Design-Output klar nachvollziehbar sein.
- Wenn ein UI-Element Teil eines Usability-Tests war oder aus einem Research-Finding resultiert, gehört auch dieser Zusammenhang dokumentiert.
Rein ästhetische oder markenspezifische Designentscheidungen müssen regulatorisch nicht dokumentiert werden.
Warum es trotzdem sinnvoll sein kann, mehr zu dokumentieren
Trotzdem kann es sich lohnen, die Prinzipien der Traceability über die regulatorische Mindestanforderung hinaus anzuwenden.
Denn sobald Sie auch weniger sicherheitsrelevante Designentscheidungen kurz dokumentieren – zum Beispiel „Warum ist dieses Icon hier?“ oder „Weshalb wurde dieser Workflow geändert?“ – entsteht ein gemeinsames Design-Gedächtnis.
Das bringt gleich mehrere Vorteile:
- Klarheit im Team: Neue Teammitglieder verstehen schneller, warum etwas so ist, wie es ist.
- Konsistenz: Designs bleiben über Versionen, Workflows – ggf. sogar Produkte – hinweg stimmig, weil Entscheidungen begründet und auffindbar sind.
- Zeitersparnis: Design-Diskussionen können abgekürzt werden.
- Qualität: Entscheidungen werden bewusster getroffen, weil sie erklärbar sein müssen.
Dem gegenüber stehen vor allem zwei Nachteile:
- Die Dokumentation kostet Zeit
- Es braucht ein praxistaugliches, leichtgewichtiges System, um sie durchzuführen.
Abschließende Gedanken
Ob ein rein auf die regulatorische Pflicht ausgerichtetes Traceability-System oder eine darüber hinausgehende Dokumentation von Design-Entscheidungen für Sie und Ihr Produkt die richtige Wahl ist, obliegt Ihrer Entscheidung.
Aus der persönlichen Erfahrung in mittlerweile über 400 erfolgreichen Projekten kann ich Ihnen sagen: In der Praxis hat es sich immer wieder bewährt, auch kleinere Designentscheidungen auf einfache Weise zu dokumentieren. Zu oft haben wir gesehen, dass Diskussionen über bereits getroffene Entscheidungen erneut aufflammen, weil die Gründe dafür verloren gegangen sind – und das kostet im Nachhinein meist mehr Zeit als die kurze Dokumentation im Moment der Entscheidung.
Ich sehe das so: gerade im UI-Design, wo oft kreative Freiheit und regulatorische Strenge aufeinandertreffen, ist Traceability so etwas wie eine gemeinsame Sprache zwischen beiden Welten.
Damit sind wir am Ende dieses Artikels angekommen. Wenn Sie tiefer einsteigen möchten, lade ich Sie herzlich zu meinem Webinar „Trace me if you can – How to keep track of medical device UI design decisions“ ein.
In 30 Minuten erhalten Sie erweiterte Einblicke in:
- Traceability aus regulatorischer Sicht
- Design-Entscheidungsfallen aus realen Projekten, in die Teams immer wieder tappen
- Beispiele für die Umsetzung von Traceability und Design-Rationale in der Praxis
Hier können Sie sich anmelden.
Vielen Dank fürs Lesen – und falls Traceability für Sie am Anfang auch „vor allem eins: trocken“ klang, hoffe ich, dass Sie jetzt ein kleines bisschen anders darüber denken. 😉
