Der Begriff Tracebility (auf deutsch Nachverfolgbarkeit) wird im Kontext von Medizinprodukten in verschiedenen Kontexten unterschiedlich verstanden. Entsprechend unterschiedlich sind auch die regulatorischen Anforderungen, welche die Hersteller und anderen Akteure (z.B. Betreiber, Lieferanten) erfüllen müssen.
Sowohl mit dem Verständnis des Konzepts als auch mit dem Erfüllen der regulatorischen Anforderungen tun sich viele Organisationen schwer. Dieser Artikel gibt Hilfestellungen.
1. Traceability: Die Kontexte
Kontext 1: Die Traceability von Anforderungen
Zum einen geht es bei der Traceability im Kontext von Anforderungen. Dabei sind zwei Unterfälle zu unterscheiden.
- Vertikale Traceability
Hersteller und Auditoren wollen verstehen, woher Anforderungen kommen z.B. wie sich die Systemanforderungen aus den Stakeholder-Anforderungen ableiten.
Damit möchte man sicherstellen, dass keine Anforderungen einer früheren Phase vergessen und keine unnötigen Anforderungen in einer späteren Phase erfunden werden. - Horizontale Tracability
Zum anderen will man sicherstellen, dass es zu jeder Anforderung die notwendigen Tests (Verifizierung, Validierung) gibt. Auch will man verstehen, welche Anforderungen nicht mehr erfolgreich überprüft sind, wenn ein Test fehlschlägt.
Ein Sonderfall dieser Traceability ist das Nachverfolgen risikominimierender Maßnahmen zu den zugehörigen Tests.
Die Abbildung 1 zeigt die „Traces“ bei der horizontalen und vertikalen Traceability.
Die für Medizinprodukte spezifischen Normen wie die ISO 14971 und die IEC 62304 stellen teilweise konkrete Anforderungen an die Traceability.
Die Podcast-Episode mit Beat Keller und Professor Johner gibt eine Übersicht über das Thema Traceability und welche geforderten Dimensionen der Traceability wie abgedeckt werden können.
Diese und weitere Podcast-Episoden finden Sie auch hier.
Kontext 2: Materialien und Bauteile
Hersteller von Produkten müssen wissen, welche Bauteile, Komponenten und Materialien in jedem einzelnen ihrer Medizinprodukte verbaut sind und von wem diese stammen. Nur so können sie,
- feststellen, welche ihrer Produkte von einem fehlerhaften Bauteil, Komponente oder Material betroffen sind,
- damit entscheiden, welche Produkte im Markt von einem möglichen Rückruf betroffen sind,
- die jeweiligen Lieferanten für Fehler haftbar zu machen.
Diese Nachvollziehbarkeit verlangen Normen wie die ISO 13485.
Kontext 3: Produkte im Markt
Sobald der Hersteller seine Produkte in den Markt bringt, muss er diese im Markt nachverfolgen können. Auch das ist eine Form von „Traceability“.
Insbesondere die MDR und IVDR legen auf diese Nachverfolgbarkeit wert, weshalb sie die Hersteller unter anderem zu einer eindeutigen Identifizierung der Produkte, Unique Device Identification, und deren Registrierung in der EUDAMED verpflichten.
2. Traceability und IEC 62304
Die IEC 62304 verlangt die Traceability u.a.
- von den System-Anforderungen zu den Software-Anforderungen
- von den Software-Anforderungen in die Software-Architektur
- vom detaillierten Design zur Software-Architektur
- von den Software-Systemtests zu den Software-Anforderungen
- der SOUPs, der Software of Unknown Provenance
Dieses Kapitel geht nur auf zwei der verlangten Traces ein.
a) Traceability zwischen Software-Anforderungen und Software-Architektur
„Der Hersteller muss verifizieren und dokumentieren, dass die Software-Architektur die System- und Software-Anforderungen […] implementiert“ lautet die Forderung der IEC 62304 im Kapitel 5.3.6 zur Verifizierung der Software-Architektur. Ein kurzer Satz, der viele Herstellern fragen lässt: „Und wie mache ich das?“
Diese Nachverfolgung der Software-Anforderungen zur Software-Architektur ist alles andere als trivial. Oft gelingt es noch, die Anforderungen eindeutig zu nummerieren. Ab wie soll man von dort auf ein einziges Architektur-Dokument verlinken können? Ein Dokument, in dem die verschiedensten architekturellen Aspekte behandelt werden: Von der Wahl der Programmiersprache über ER-Diagramme für die statische Sicht bis hin zu UML-Verteilungsdiagrammen und Begründungen für bestimmte Architekturpattern.
Antipatterns
Diese Verbindung (die Traceability zwischen Requirements und Architektur) wird besonders dann Schwierigkeiten bereiten, wenn das Architekturdokument viel (unstrukturierten) Fließtext enthält. Fließtext ist manchmal herausfordernd. Denn unsere Sprache ist so vielgestaltig und nuanciert, dass die Eindeutigkeit schnell leidet:
Eine Passivkonstruktion, und schon muss man über den Akteur keine Aussage machen. Ein Konjunktiv, und schon bleibt es im Unklaren, ob dieser Aspekt verpflichtend ist oder nicht, oder nur eine Überlegung des Autors wiedergibt.
Dennoch kann es hilfreich sein mit Fließtext den Kontext zu beschreiben.
Best Practices
Daher das Plädoyer:
- Nutzen Sie lieber Modelle statt Text. Hier sind die Ausdrucksmöglichkeiten sehr eingeschränkt und die Aussagen damit eindeutiger. Modelle in Form von Bildern erlauben einen schnellen Überblick und einfachere Diskussion.
- Halten Sie Ihr UML-Diagramm „sauber“ von zu vielen Metadaten. Verunstalten Sie es nicht durch Links zu den Software-Anforderungen. Ich empfehle Ihnen aber, im UML-Klassen/Komponentendiagramm die Sicherheitsklassen gemäß IEC 62304 (farblich) zu kennzeichen, ebenso Komponenten anderer Hersteller (SOUPs).
- Strukturieren Sie das Architektur-Dokument in viele Kapitel. Ein Textabschnitt sollte eine halbe Seite nicht überschreiten, bevor er durch eine neue Überschrift unterbrochen wird. So können Sie über die Überschriften relativ genau auf einen Architekturaspekt verweisen (verlinken): „realisiert in Komponente X (siehe Kapitel m)“, „wird berechnet durch Methode Y (siehe Kapitel n)“, „ist gelöst durch Wahl der Technologie Z (siehe Kapitel o)“.
- Fügen Sie ein eigenes Kapitel (ggf. sogar ein eigenes Dokument) ein, das der Traceability gewidmet ist. Listen Sie darin die Anforderungen (erneut) auf und schreiben Sie zu jeder einen ganz kurzen Satz mit einem Verweis auf eines dieser Teilkapitel im Architekturdokument.
b) Traceability zwischen Software-Anforderungen und Software-Systemtests
Das Tracing zwischen Software-Anforderungen und Software-Systemtests gestaltet sich hingegen oft etwas einfacher, da Sie sowohl die Software-Anforderungen als auch die Software-Systemtests (im Gegensatz zu Architekturaspekten) einfach durchnummerieren können.
Allerdings benötigt man für diese Traceability zwischen beiden eine n:m-Beziehung. Das lässt sich über eine Tabelle ausdrücken, die zeigt, welche Systemtests welche Anforderungen testen, und welche Anforderungen durch welche Systemtests geprüft werden. Noch mehr eigenen sich Werkzeuge (s.u.).
3. Traceability bei weiteren Normen
a) ISO 14971
Ähnlich der Beziehung zwischen Software- bzw. System-Anforderungen und Software- bzw. Systemtests verhält es sich bei der ISO 14971. Die Norm fordert die Traceability
- zwischen Risiken und Maßnahmen zur Risikobeherrschung und
- zwischen Maßnahmen und der Verifizierung der Maßnahmen (genauer mit der Überprüfung, ob diese implementiert und wirksam sind).
Beide Beziehungen pflegen Hersteller üblicherweise in einer „Risiko-Tabelle“, die manchmal auch fälschlich als „FMEA-Tabelle“ bezeichnet wird.
b) IEC 60601-1
Die IEC 60601-1 kennt ähnliche Anforderungen an die Nachvollziehbarkeit wie die bereits genannte IEC 62304. Sie enthält im Anhang auch die Abbildung, die diese Traces zeigt und die oben schematisch wiedergegeben ist.
Die IEC 60601-1 verlangt zudem, dass die Änderungen nachvollzogen werden können. Man muss wissen, wer eine Änderung beantragt, wer diese genehmigt, wer deren Auswirkungen analysiert, wer diese umgesetzt und wer für den Markt freigegeben hat.
c) ISO 13485
Die ISO 13485 fordert an mehreren Stellen eine Traceability
- Kapitel 7.1: Hier geht es um die vertikalen Traces (s. Abb. 1)
- Kapitel 7.3.2: Das Tracing zwischen Design Inputs und Design Outputs entspricht den horizontalen Traces.
- Kapitel 7.4: Die Norm besteht auf die Nachvollziehbarkeit, woher eingekaufte Produkte, Komponenten, Bauteile, Materialien usw. stammen. Das entspricht dem „Kontext 2“.
- Kapitel 7.5.1: Nun geht es um die Nachverfolgbarkeit des einzelnen Produkt auch vor Auslieferung.
- Kapitel 7.5.9: Dieses Kapitel ist sogar mit „Traceability“ überschrieben. Es verlangt, dass die Hersteller ihre (ausgelieferten) Produkte konform mit den regulatorischen Anforderungen nachverfolgen können. Damit sind auch die UDI-Anforderungen gemeinst.
4. Traceability und MDR / IVDR
Die MDR und IVDR widmen ein ganzes Kapitel der Traceability. Daran formulieren sie die Anforderungen an die UDI und EUDAMED.
Auch der Implantationsausweis (Artikel 18) dient der Nachverfolgung von Produkten, konkret Implantaten. Aber in diesem Kontext nutzt die MDR den Begriff „Traceability“ nicht.
5. Werkzeuge für die Traceability
a) Allgemeines
Die Word-gestützte Dokumentation ist schwierig. Auch der „Marktführer“ für das Tracing, Microsoft Excel, stößt schnell an seine Grenzen. Das gilt besonders, weil die Verlinkung über Dokumentengrenzen hinweg funktionieren soll. Aber das ist ja genau der Grund für Werkzeuge wie MedPack und RiskPack.
Mit solchen Werkzeugen ist es einfacher, das Traceability-Chaos in den Griff zu bekommen. Das finden übrigens auch die Auditoren. Denn diese Tools haben sich in vielen Audits bewährt. Nicht nur deren Auswertungen wegen ist es einfacher, fehlendes Traces direkt anzuzeigen.
b) Anforderungen an Werkzeuge
Werkzeuge sollten folgende Fragen zu beantworten helfen:
- Welche Anforderungen (auf allen Ebenen) wurden durch Tests überprüft? Waren diese erfolgreich?
- Welche Tests müssen noch(mals) durchgeführt werden?
- Woher stammen die Anforderungen? Lassen sich beispielsweise die Software-Anforderungen auf Systemanforderungen zurückführen?
- Wie werden die Anforderungen umgesetzt? Welche Anforderungen wurden umgesetzt, welche noch nicht? Beispielsweise müsste sichergestellt sein, dass alle Stakeholder-Anforderungen z.B. durch Systemanforderungen umgesetzt werden.
- Gibt es Tests, die neu entwickelt werden oder erneut durchlaufen werden müssen, wenn sich eine Anforderung ändert? Welche sind das?
- Welche Anforderungen sind nicht überprüft, wenn ein Test scheitert?
Werkzeuge sollte weitere Anforderungen ergänzen z.B.:
- Standortübergreifende Nutzen
- Implementierung eines Rollenkonzepts, ggf. unter Nutzung bestehender Verzeichnisdienste und Autorisierungsmechanismen
- Berichte erzeugen oder Dashboards bereitstellen, die helfen, die obigen Fragen zu beantworten
- Interoperabilität z.B. Import von Anforderungen aus Word, Integration mit Entwicklungs- und Testwerkzeugen
6. Fazit, Zusammenfassung
Der Begriff der Traceability, zu deutsch Nachverfolgbarkeit, wird in verschiedenen Kontexten benutzt. Hersteller sollten
- diese Kontext kennen und unterscheiden können,
- die jeweilig gültigen regulatorischen Anforderungen kennen und erfüllen und
- Werkzeuge nutzen, um die aufwändige und fehlerträchtige Arbeit zu vereinfachen, diese „Traces“ zu dokumentieren und aktualisieren.
Änderungshistorie
- 2023-11-11: Neues erstes Kapitel eingefügt, das die verschiedenen Kontexte vorstellt, in dem es um Traceability geht. Die Kapitel mit den Normen neu strukturiert. Anforderungen der MDR ergänzt.
- 2020-09-30: Erste Version des Artikels
Ich halte die Verwendung von UML-Diagrammen im Rahmen der Architekturdokumentation für absolut nützlich, weil man komplexe Sachverhalte wie z.B. eine Multi-Tier-Architektur und die Beziehung zwischen den Schichten einfach viel besser visualisieren kann, als sie in Prosa zu beschreiben.
Separate Beschreibungen ein und derselben Abstraktionselemente für bestimmte Einsatzzwecke erzeugen IMHO nur double-maintenance.
Ein Software-Modell in UML-Notation abzubilden hat viele Vorteile, weil man Projektartefakte aus verschiedensten Blickwickeln aus einer *konsistenten* Quelle erstellen kann: Architektur, Risikomanagement, Traceability, Test, Implementierung, usw.
Die Information liegt also gebündelt vor, jedes Modellelement wird genau einmal definiert, kann aber in verschiedenen Kontexten und in verschiedenen Sichten dargestellt werden (je nach dem, welche Information im jeweiligen Kontext benötigt wird).
Außerdem sind die meisten UML-Tools in der Lage, einen Export und Import von Modellen in portablen Formaten wie z.B. XML durchzuführen. Durch geeignete Scripte kann man leicht „Metadaten“ einfügen oder automatisch verarbeiten.
Aber warum überhaupt proprietäre Metadaten verwenden? Die UML bietet für solche Zwecke wie die Kennzeichnung gleichartiger Modellelemente das Mittel der Stereotypen an. Damit kann man leicht risikorelevante Elemente von anderen unterscheiden (und vieles Andere mehr).
Eine manuelle farbliche Kennzeichnung scheint mir im Vergleich dazu weit anfälliger für Fehlinterpretationen und out-dating zu sein.
Aber vielleicht ist das ja alles mehr eine Frage des persönlichen Geschmacks 😉
Sehr geehrter Herr Tietjen,
danke für Ihre Ergänzungen.
Ich bin nicht ganz sicher, ob es mir gelungen ist, mich verständlich zu artikulieren. Wenn der Eindruck entstanden wäre, dass ich UML-Diagramm für ungeeignet halte, wäre das exakt das Gegenteil dessen, was ich ausdrücken wollte.
Ich stimme Ihnen absolut zu, dass Stereotypen geeigneter sind, um Sicherheitsklassen zu charakterisieren, als eine (nur) farbliche Kennzeichnung.
Nochmals besten Dank!
Christian Johner
Hallo Herr Johner,
der Empfehlung, „UML-Diagramme“ nicht mit Anforderungen zu verunstalten, kann ich mich nicht anschliessen.
Ein gutes Werkzeug, welches Mehr als nur Diagramme zeichnen lässt, sondern ein Modell verwaltet besitzt eben diesen Vorteil, die Notwendigkeit eines AArchitekturelements durch Anforderungen nachweisen zu können.
Besonders, wenn die Architektur aufgrund einer Modelländerung/Anforderungsänderung verändert werden muss, ist so eine schnelle Prüfung des Einflusses möglich und die Tragweite der Anforderungsänderung kann plausibel abgeschätzt werden.
Ebenso verhält es sich mit den Risikomitigationen, da diese damit an ein Modellelement geknüpft sind und sich die Auswirkung der Codeänderung auf Risikomitigationen, oder deren Nicht-Auswirkung dokumentiert nacgewiesen ist.
In Kurz:
Durch die Verknüpfung Modellelement und Anforderung wird eine Impactanalyse vereinfacht und das Projekt/Produkt wartbarer gestaltet.
Beste Grüße
Stefan Bolleininger
Sehr geehrter Herr Bolleininger,
danke für Ihre wertvollen Gedanken. Die Verlinkung von Anforderungen im Architektur-Diagramm kann durchaus funktionieren, da bin ich ganz bei Ihnen. Es funktioniert v.a., wenn man nicht 1000e Anforderungen zu tracen hat, wenn das Modell so detailliert erstellt wurde, dass man die Traces überhaupt sinnvoll lokalisieren kann und wenn die Anforderungen sich überhaupt im Modell abbilden lassen.
Viele Grüße
Christian Johner
Neben der hier erwähnten Traceability von Anforderungen-Implementation-Tests gibt es noch mindestens zwei weitere Traceabilities welche Medizinproduktehersteller nicht vergessen sollten:
1. Traceability der Medizinprodukte: welche Materialien/Komponenten habe ich als Hersteller in welches Medizingerät verbaut und wo ist das Gerät hin? Fehlt mir diese Traceability, wird der Rückruf oder eine Feldmassnahme zum (noch grösseren) Albtraum.
2. Traceability oder Rückführbarkeit der Messergebnisse. Ist das 1V dass ich gemessen habe auch 1 Volt oder wären es doch 2V gewesen? Ohne eine Sicherheit dass die Messergebnisse (im Rahmen der Messunsicherheit) stimmen, kann ich als Hersteller nicht sicherstellen, dass das Gerät funktioniert wie es sollte.
Danke für die hilfreiche Ergänzung, Herr Keller!
Guten Tag Herr Johner,
erst mal ein großes Lob und vielen Dank für Ihre hilfreichen Artikel.
Beat Keller hatte in seinem Kommentar (2020-10-19) bereits indirekt die Frage gestellt, ob die Nachverfolgbarkeit von Mess-/Prüfmitteln einen weiteren (4.) Kontext darstellt, in den dann evtl. auch noch die Dokumentation von Prüfungen während der Herstellung, Endabnahmen usw. fallen könnten.
Mit Sicherheit haben Sie oder Ihre Kollegen sich auch mit der 21 CFR – Part 821 Medical Device Tracking Requirements befasst. Ich denke dieser Paragraf der FDA behandelt selbige Thematik, geht aber noch weiter als die MDR, z. B. die Verfolgbarkeit bis zu Versanddokumenten usw.
Ich würde mich sehr freuen, wenn Sie oder Ihr Team die Zeit finden, die Perspektiven „Messmittelüberwachung“ und „FDA Tracking“ in Ihren Artikel zur Traceability aufzunehmen.
Mit freundlichen Grüßen
Sehr geehrter Herr Frisch,
haben Sie vielen Dank für Ihre Anmerkungen und den Vorschlag zur Vervollständigung. Tatsächlich steht dieser Fachartikel auf unserer Liste für „überarbeitungswürdige Fachartikel“. Ich werde Ihren Vorschlag gern berücksichtigen.
Mit besten Grüßen
Sophie Bartsch