Begriffe und Definitionen für Medical Device Software – IEC 62304 & FDA (Teil 1)

Dieser Artikel ist Teil einer Serie über die IEC 62304, die sich mit dem Verständnis der Norm und ihrer korrekten Umsetzung in der Softwareentwicklung für Medizinprodukte befasst.

Previous Articles:

• Wie beginnt man mit der Implementierung der IEC-62304-Norm?

In diesem ersten Teil konzentrieren wir uns auf Begriffe und Definitionen, die häufig Gegenstand von Diskussionen und Fehlinterpretationen sind, insbesondere im Zusammenhang mit Softwarearchitektur und Dekomposition.

• Was ist eine ANOMALIE?
• Was ist ein KONFIGURATIONSELEMENT - CONFIGURATION ITEM?
• Was ist ein ZU LIEFERNDES ERGEBNIS - DELIVERABLE?
• Was ist ein SOFTWARE-KOMPONENTE - SOFTWARE ITEM?
• Was ist eine SOFTWARE-EINHEIT - SOFTWARE UNIT?

Begriffsabklärung für eine bessere Kommunikation

Haben Sie sich schon einmal in einer Diskussion mit Kollegen wiedergefunden, nur um festzustellen, dass Sie sich im Kreis drehen, weil Sie unterschiedliche Begriffe verwenden oder sie unterschiedlich interpretieren? Dies ist eine häufige Situation, die ich in Kundenberatungen erlebe. Deshalb empfehle ich immer, mit einer Begriffsabklärung zu beginnen und ein gemeinsames Verständnis zu schaffen.

Eine eindeutige Interpretation der Begriffe ist für die Arbeit mit der Norm unerlässlich, da in den folgenden Kapiteln auf diese Begriffe verwiesen wird, ohne sie erneut zu erklären.

Dabei geht es nicht darum, die „beste“ Interpretation zu finden, sondern einen Konsens zu erzielen. Ohne ein gemeinsames Verständnis wird es schwierig, Probleme klar zu beschreiben und effektiv zu lösen.

Angleichung der IEC-62304-Terminologie an FDA-Leitlinien

Ich stoße häufig auf zwei zentrale Herausforderungen:

1. Unterschiedliche Interpretationen des Abschnitts „Begriffe und Definitionen“ in der IEC 62304.
2. Abweichungen in der Terminologie zwischen der IEC 62304 und verschiedenen FDA-Leitlinien, die für die Medizinproduktebranche relevant sind.

In diesem Artikel werden wir beide Herausforderungen behandeln. Wir beginnen mit den Begriffen und Definitionen aus der IEC 62304 und ergänzen ihre Interpretation mit Erkenntnissen aus relevanten FDA-Leitlinien.

Wo kann man die IEC 62304 kaufen?

Im ersten Teil dieser Serie, Wie beginnt man mit der Implementierung der IEC-62304-Norm?, habe ich eine alternative Quelle für den Erwerb der Norm zu einem günstigeren Preis als auf den offiziellen ISO- oder IEC-Websites empfohlen. Sie ist auf der Webseite des Estonian Centre for Standardisation and Accreditation EVS . Hier ist der direkte Link zur IEC 62304, einschließlich der Änderung von 2015.

Ich weise Sie erneut darauf hin, lieber eine Mehrfachlizenz zu erwerben.

Wichtige Begriffe und Definitionen für Medical Device Software aus der IEC 62304

Der Abschnitt Begriffe und Definitionen befindet sich in Kapitel 3. Trotz seines Titels klärt er nicht immer alle Begriffe umfassend. Häufig ist es notwendig, weitere Normen heranzuziehen, um ein vollständiges Verständnis zu erhalten. Im Folgenden werde ich einige der komplexeren Begriffe in einfacher Sprache erklären – so, wie ich sie auch in Kundengesprächen darstelle. Ich konzentriere mich auf die Begriffe, die Ihnen in Ihrer Arbeit mit der Norm und der Entwicklung von Software für Medizinprodukte am häufigsten begegnen werden.

In dieser Serie lassen wir bewusst Begriffe aus, die sich auf das Risikomanagement beziehen, da wir dieses Thema separat behandeln werden. Ebenso überspringen wir Begriffe, die selbsterklärend oder für die Arbeit mit der Norm weniger relevant sind.

Was ist eine ANOMALIE in der IEC 62304?

Definition: Eine Anomalie ist jede Abweichung von einem erwarteten oder beabsichtigten Ergebnis. Dies kann eine funktionale Abweichung in der Software eines Medizinprodukts, Inkonsistenzen in der Dokumentation oder Defizite in den Anforderungen des Qualitätsmanagements betreffen.

Anomalien sind nicht nur Softwarefehler

Viele interpretieren eine Anomalie als einen fehlgeschlagenen Test. Das liegt daran, dass die IEC 62304 Anomalien hauptsächlich in Abschnitt 5.7 behandelt, der sich auf das Software-Systemtestverfahren konzentriert. Allerdings können Anomalien viele verschiedene Formen annehmen, darunter:

• Eine Softwareanforderung, die mehrdeutig definiert ist, sodass unklar bleibt, wie sich die Software verhalten soll. In diesem Fall liegt das Problem nicht in einem Fehlverhalten der Software selbst, sondern in einer unklaren Beschreibung.
• Eine Systemreaktion, die unter bestimmten Testbedingungen langsamer als erwartet ist. Falls diese Verzögerung durch eine weniger leistungsfähige Testumgebung verursacht wird und nicht durch ein tatsächliches Softwareproblem, stellt sie möglicherweise kein Problem für das Endprodukt dar.

Anomalien führen nicht zwangsläufig zu einer verzögerten Softwarefreigabe

Die Erkenntnis, dass Anomalien nicht nur Softwarefehler sind, ist entscheidend, da sie eine flexiblere Handhabung ermöglicht. Das Vorhandensein einer Anomalie bedeutet nicht automatisch, dass eine Softwareveröffentlichung gestoppt werden muss.

Natürlich sollte keine medizinische Software mit bekannten funktionalen Fehlern freigegeben werden. Allerdings sind kleinere Inkonsistenzen, die die Funktionalität nicht beeinträchtigen, nicht unbedingt ein Grund, die Einführung zu verzögern. Viele Unternehmen erschweren sich diesen Prozess unnötig, indem sie interne Vorschriften festlegen, die jede Veröffentlichung von Software mit Anomalien verbieten.

Selbst die IEC 62304 erlaubt die Freigabe von Software mit bekannten Anomalien nach einer entsprechenden Analyse, wie in Abschnitt B.5.7 beschrieben.

Was ist ein KONFIGURATIONSELEMENT (CONFIGURATION ITEM) in der IEC 62304?

Minimale Definition in der Norm

Die IEC 62304 gibt eine knappe Definition und beschreibt ein KONFIGURATIONSELEMENT als “alles, was zu einem bestimmten Zeitpunkt eindeutig identifiziert wird.“

Ein besseres Verständnis erhält man durch die IEC 12207, eine referenzierte Norm, die wertvolle Einblicke in System- und Software-Lebenszyklusprozesse bietet.

Was ist ein KONFIGURATIONSELEMENT?

Ein KONFIGURATIONSELEMENT (Configuration Item, CI) ist jedes Element, das mit der Software Ihres Medizinprodukts in Verbindung steht und eindeutig identifiziert sowie aktualisiert werden muss, um Klarheit in der Entwicklung und Wartung zu gewährleisten.

Typische KONFIGURATIONSELEMENTE sind:

• Software-Anforderungsspezifikationen
• Software-Architektur
• Test-Spezifikationen
• Risikomanagement- oder Cybersecurity-Dokumentation
• Quellcode (einschließlich kompilierter Code)
• Externe Bibliotheken (SOUP oder OTS)
• Entwicklungs- und Deployment-Tools (z. B. IDEs, Compiler, CI/CD-Konfigurationen wie GitHub, Dockerfiles, Kubernetes YAML, Jenkinsfiles)
• Testumgebungen
• Benutzerhandbücher

Das Verständnis dieses Begriffs ist wichtig, da sich Kapitel 8 der IEC 62304, „Software-Konfigurationsmanagement-Prozess,“ ausschließlich mit der Verwaltung von Konfigurationselementen befasst.

Eine separate Norm, IEEE 828-2012 – Configuration Management in Systems and Software Engineering, bietet zusätzliche Leitlinien zum Konfigurationsmanagement.

Was ist ein ZU LIEFERNDES ERGEBNIS (DELIVERABLE) in der IEC 62304?

Ein ZU LIEFERNDES ERGEBNIS (Deliverable) ist jedes Ergebnis, das aus einer bestimmten Aktivität hervorgeht. In der Entwicklung von Software für Medizinprodukte umfasst dies nicht nur den Quellcode, sondern auch die technische Dokumentation.

Dies zu erkennen ist wichtig, da die IEC 62304 erwartet, dass ZU LIEFERNDE ERGEBNISSE nachvollziehbar und überprüfbar sind. Dies gilt nicht nur für den Quellcode, sondern auch für Dokumente wie:

• Software-Anforderungsspezifikation (SRS)
• Software-Architektur
• Risikomanagement-Dokumentation

Wie man sieht, überschneiden sich ZU LIEFERNDE ERGEBNISSE häufig mit KONFIGURATIONSELEMENTEN (Configuration Items).

Was ist ein SOFTWARE-KOMPONENTE (SOFTWARE ITEM) in der IEC 62304?

Der Begriff SOFTWARE-KOMPONENTE (Software Item) in der IEC 62304 führt oft zu Verwirrung. Viele legen zu großen Wert auf eine genaue Definition, obwohl die Norm den Begriff flexibel verwendet.

Definition: Ein SOFTWARE-KOMPONENTE ist jedes Software-Element, das während der Dekomposition identifiziert wird. Es kann beliebig gewählt werden, solange es aus irgendeinem Grund als eigenständiger Bestandteil betrachtet wird.

Anstatt die Definition unnötig zu verkomplizieren, sollten SOFTWARE-KOMPONENTEN so definiert werden, dass sie den Softwareentwicklungsprozess unterstützen. Halten Sie sich an etablierte Architekturprinzipien.

Beispiele für SOFTWARE-KOMPONENTEN:

• Frontend-Anwendung

  • Kommunikation mit Backend
  • Benachrichtigungen und Alarme
  • Sichere Eingabeverarbeitung

• Backend-Anwendung

  • Datenbank
  • Benutzer-Authentifizierung
  • Audit-Logging
  • REST API
  • HL7/FHIR-Schnittstellen

Was ist eine SOFTWARE-EINHEIT (SOFTWARE UNIT) in der IEC 62304?

Eine SOFTWARE-EINHEIT (Software Unit) ist das kleinste unteilbare SOFTWARE-KOMPONENTE (Software Item).

Zum Beispiel: Wenn “Kommunikation mit Backend“ als SOFTWARE-KOMPONENTE definiert ist und nicht weiter unterteilt wird, dann ist es gleichzeitig eine SOFTWARE-EINHEIT.

Die Granularität von SOFTWARE-EINHEITEN wird vom Hersteller festgelegt, abhängig von den Anforderungen an Wartung, Sicherheit, Zuverlässigkeit und Skalierbarkeit.

Software-KOMPONENTEN und SOFTWARE-EINHEITEN sind ebenfalls KONFIGURATIONSELEMENTE (Configuration Items).

Was kommt als Nächstes?

Im nächsten Artikel werden wir weitere Begriffe und Definitionen aus der IEC 62304 behandeln.

Falls Sie Unstimmigkeiten entdecken oder eine andere Perspektive haben, zögern Sie nicht, uns zu kontaktieren – Ihr Feedback und Diskussionen sind willkommen!