Hersteller müssen für Medizinprodukte-Software fast immer eine Software-Architektur entwerfen und diese verifizieren.

Inhalt

Diese Seite verschafft Ihnen einen schnellen Überblick und verlinkt zu weiterführenden Artikeln.

  1. Grundlagen
  2. Software-Architektur im Produktlebenszyklus
  3. Regulatorische Anforderungen
  4. Fünf Praxistipps
  5. Unterstützung

1. Grundlagen

a) Ziel

Die Software-Architektur dient dem Software-Entwicklungsteam als Input, um die Software wie geplant (Zeit, Geld, Qualität) entwickeln zu können. Sie soll damit Entwicklungsrisiken minimieren und sicherstellen, dass die Software die Software-Anforderungen erfüllt.

b) Definition

Unter Software-Architektur versteht man sowohl eine Phase mit einem Satz an Aktivitäten als auch das Ergebnis dieser Aktivitäten. Die meisten Definitionen zielen auf das letztere.

Definition:  Software-Architektur

Die Software-Architektur ist die Zerlegung eines Software-Systems in Komponenten und die Spezifikation der Schnittstellen zwischen diesen Komponenten.

Quelle: Johner Institut, angelehnt an IEEE

Eine anschauliche Definition stammt von Martin Fowler:

Definition:  Software-Architektur

Die Menge aller wichtigen und schwer änderbaren Entscheidungen

2. Software-Architektur im Entwicklungslebenszyklus

a) Standalone-Software (Software as a Medical Device)

Bei Standalone-Software ist die Software-Architektur der „Bauplan“, der vorgibt, wie die Software-Anforderungen (der Input) in Software umgesetzt werden soll (s. Abb. 1). Als Output entsteht in dieser Phase die dokumentierte Software-Architektur. Dazu zählen die Software-Komponenten und die Anforderungen daran.

Bild zeigt V-Modell. Standalone Software: Die Software-Architektur hat als Input die Software-Anforderungen und als Output die dokumentierte Software-Architektur

Abb. 1: Die Phase „Software-Architektur“ hat als Input die Software-Anforderungen und als Output die dokumentierte Software-Architektur.

Die Abbildung 1 erinnert an ein V-Modell. Sie ist aber eher als Dokumentationsmodell für die Software-Entwicklung zu verstehen und nicht als Prozessmodell.

b) Software als Teil eines Produkts (Software in a Medical Device)

Auch bei Software, die Teil eines Produkts ist, dienen die Software-Anforderungen als Input für die Software-Architektur. Sie entsprechen aber nicht den System- bzw. Produktanforderungen (s. Abb. 2 und Tipp 1).

Bild zeigt V-Modell: Auch bei embedded Software hat die Software-Architektur-Phase als Input die Software-Anforderungen und als Output die dokumentierte Software-Architektur.

Abb. 2: Auch bei Software, die Teil eines Produkts ist, hat die Phase „Software-Architektur“ als Input die Software-Anforderungen und als Output die dokumentierte Software-Architektur.

Der Output ist auch hier die dokumentierte Software-Architektur, einschließlich der Anforderungen an die Komponenten.

Hinweis

Die IEC 62304 legt zwar fest, dass der Entwicklungsplan die Vorgaben für Werkzeuge, Methoden und Kodierrichtlinien machen soll. Oft sind diese Festlegungen aber erst sinnvoll möglich, wenn die Software-Architektur steht.

c) Zusammenspiel mit dem Risikomanagement

Bei Medizinprodukten müssen die Software-Architektur und das Software-Risikomanagement Hand in Hand arbeiten. Das betrifft insbesondere die Risikoanalyse bei Software, beispielsweise mithilfe einer Software-FMEA oder des Threat Modelings.

In dieser Phase sollten auch risikominimierende Maßnahmen wie die Segregation von Komponenten festgelegt werden.

d) Abgrenzung (Baucharchitektur)

Bauarchitekten erstellen im Gegensatz zu Software-Architekten nicht nur den Bauplan. Sie ermitteln (gemeinsam mit dem Bauherrn) auch die Stakeholder-Anforderungen.

Die Software-Architekten sollten nur den Bauplan (die Software-Architektur) erstellen. Die Anforderungen zu erheben, ist Aufgabe des Requirements-Engineering.

Regulatorische Anforderungen

Europa

MDR, IVDR

Die MDR und IVDR verlangen Software-Lebenszyklus-Prozesse nach Stand der Technik (s. MDR, Anhang I, Abschnitt 17.2) und die „Beschreibung des Software-Designs“ (s. Anhang II, Abschnitt 6.1.b).

IEC 62304

Die für diese EU-Verordnungen harmonisierte Norm IEC 62304 schreibt in den Kapitel 5.3 und 5.4 eine Software-Architektur und ein detailliertes Software-Design vor. Dazu müssen die Hersteller die Software-Komponenten und Software-Einheiten identifizieren und die entsprechenden Schnittstellen spezifizieren.

Falls die Hersteller Off-the-shelf-Software (SOUP) verwenden, müssen sie auch dafür die Anforderungen spezifizieren und die Voraussetzungen für deren Einsatz dokumentieren und gewährleisten.

Die Norm verpflichtet die Hersteller dazu, die Software-Architektur zu verifizieren, ob beispielsweise alle Anforderungen berücksichtigt und Maßnahmen zur Risikobeherrschung umgesetzt sind.

USA

Die FDA erkennt die IEC 62304 als „recognized standard“ an. Aber die relevantesten Vorgaben an die Software-Architektur formuliert die Behörde in ihrer Leitlinie General Principles of Software Validation.

Zudem gibt die Leitlinie Content of the premarket submission  vor, welche Unterlagen Hersteller einreichen müssen. Darin macht die FDA auch Vorgaben für die „Software Architecture“ und das „Software Detailed Design“.

Praxistipps

Tipp 1: Das Software-System nicht als die Gesamtheit der Software festlegen

Medizinisch-elektrische Geräte können mehr als eine CPU und damit mehr als eine „Software“ enthalten (s. Abb. 3). Hersteller sollten nicht die Gesamtheit aller Software als das Software-System definieren. Vielmehr sollte die Software für jede Prozessoreinheit (kann mehrere Kerne enthalten) als eigenes Software-System zählen.

Grafik aus Kästchen, die ein Medizinprodukt, dessen Komponenten und darin Software zeigt

Abb. 1: Ein Medizinprodukt besteht aus Komponenten. Diese wiederum enthalten Software.

Damit vermeiden Hersteller Schichtenarchitekturen und  Produkte, die gedanklich nach Gewerken in die Schichten Mechanik, Elektronik und Software unterteilt sind. Sie sollten Produkte nach funktionalen Überlegungen unterteilen.

Tipp 2: Den richtigen Zeitpunkt wählen

Es ist weder sinnvoll noch gesetzeskonform, die Software-Architektur erst nach der Software-Entwicklung zu spezifizieren und dokumentieren.

Bei der agilen Software-Entwicklung ist ein kontinuierliches Refactoring möglich und üblich. Die Erfahrung zeigt jedoch, dass die meisten Hersteller mit einer präzisen und tragfähigen Upfront-Architektur sehr gefordert sind. Die konzeptionelle Integrität einer Architektur in einer agilen Entwicklung zu bewahren, klappt nur in wenigen Fällen.

Daher ist es hilfreich, die wesentlichen Design-Entscheidungen früh und auf Basis stabiler Anforderungen zu treffen.

Tipp 3: Definierte Notation verwenden

Manche Entwickler dokumentieren die Software-Architektur mithilfe von Kästchen und Pfeilen in PowerPoint. Bei so einem Pfeil muss allerdings klar sein, was dieser bezeichnet. Eine

  • Abhängigkeitsbeziehung?
  • Assoziation? Komposition oder Aggregation?
  • Vererbungsbeziehung?
  • Datenflussrichtung?
  • Richtung der Methodenaufrufe?
  • Implementierung?

Ein Modell ist nur dann aussagekräftig, wenn die Notationselemente (Formen, Farben etc.) definiert sind. Erfinden Sie daher keine eigene Notationssprache, sondern nutzen Sie standardisierte Sprachen wie UML.

Weiterführende Informationen

Der Artikel zur Dokumentation der Software-Architektur stellt Ihnen eine bewährte Kapitelstruktur vor.

Tipp 4: Integrationsstrategie frühzeitig festlegen

Eine wesentliche Eigenschaft guter Software-Architekturen sind Komponenten, die sich im Software-System durch „weak coupling and strong cohesion“ auszeichnen. Diese schwache Kopplung ist die Voraussetzung, um die Software später stückweise aus den Komponenten zusammensetzen und integrieren zu können.

Hersteller sollten sehr frühzeitig die Integrationsstrategie bestimmen, weil sie damit von Beginn an gezwungen sind, über die Stärke der Kopplung nachzudenken. Die Integrationsstrategie hat auch Einfluss auf die Integrationstests.

Tipp 5: Verifizierung mit Checklisten

Die Architektur muss verifiziert werden, bevor entwickelt wird. Eine Änderung an der Software-Architektur bedarf einer erneuten Verifizierung (zumindest der Änderungen).

Mit Checklisten, wie sie im Auditgarant zu finden sind, lassen sich Konformität und Vollständigkeit der Software-Architektur nachvollziehbar prüfen. Damit vermeiden Hersteller, Aspekte zu vergessen.

Unterstützung

Nutzen Sie die Unterstützung des Johner Instituts:

  • Mit dem Auditgarant lernen anhand von Videotrainings, wie Sie Schritt für Schritt eine schlanke und IEC 62304 konforme „Software-Akte“ erstellen. Ein vollständiger Satz an Templates nimmt Ihnen viel Arbeit ab.

Melden Sie sich gleich, damit wir die nächsten Schritte besprechen können. So stellen Sie sicher, dass die „Zulassung“ sicher gelingt und Ihre Produkte schnell in den Markt kommen.


Software-Risikomanagement für medizinische Software

Unter Software-Risikomanagement verstehen Hersteller von Medizinprodukten entweder das Risikomanagement, das sie für die Standalone-Software betreiben müssen, oder den Teil des Risikomanagements, den eine embedded Software nach sich zieht. Regelmäßig werden Hersteller den regulatorischen Anforderungen an das Software-Risikomanagement nicht gerecht. Dieser Beitrag gibt Tipps für ein schlankes Software-Risikomanagement, mit dem Sie unnötige Aufwände vermeiden und Konformität…

Weiterlesen

Software-Schnittstellen: Beschreibung konform IEC 62304

Software-Systeme sollten aus Komponenten bestehen, die über Software-Schnittstellen miteinander kommunizieren. Dieser Artikel beschreibt, wie Sie Software-Schnittstellen dokumentieren können. Dabei zeigt er Konzepte, die sich nicht nur auf interne und externe Software-Schnittstellen, sondern auch auf Hardware-Schnittstellen übertragen lassen.  Inhaltsübersicht Dokumentation » Interne und externe Schnittstellen » Regulatorische Anforderungen » Typische Fehler »

Weiterlesen

Sicherheitsklassen gemäß IEC 62304

Die IEC 62304 hat das Konzept der Sicherheitsklassifizierung eingeführt, damit Medizinproduktehersteller den Aufwand für die Software-Dokumentation an den Grad möglicher Schäden anpassen können, die durch einen Softwarefehler verursacht würden. Dieser Artikel hilft Ihnen, die Sicherheitsklassen zu bestimmen und IEC 62304 konform zu dokumentieren. Update: Keine Konformitätsvermutung mehr bei Sicherheitsklasse A? Mehr…

Weiterlesen

MDR Software-Hersteller aufgepasst!

Viele Änderungen der neuen Medizinprodukteverordnung (MDR) betreffen alle Medizinprodukte-Hersteller. Einige dieser Änderungen wenden sich besonders an Hersteller, deren Produkte Software enthalten oder standalone Software sind. Lesen Sie, was diese Hersteller beachten sollten. Änderungen durch die MDR Definitionen und Klassifizierung » Grundlegende Anforderungen » Technische Dokumentation » Unique Device Identification »

Weiterlesen
Software-Audit: Gibt es das?

Software-Audit: Auf was es wirklich ankommt

„Findet ein Software-Audit statt?“ lautet eine Frage, die mich über unser Micro-Consulting erreicht. „Und kann ich durch eine geeignete Wahl der Software-Sicherheitsklasse so ein Software-Audit vermeiden?“ Erst ist mir weder klar, was genau mit „Software-Audit“ gemeint, noch was die genaue Befürchtung ist. Doch dann verstehe ich und finde die Frage sehr bedeutsam für alle Medizinprodukte-Hersteller.

Weiterlesen

Segregation von Software: 3 Ziele, die Sie kennen sollten

Die IEC 62304 verlangt die Notwendigkeit einer Segregation (auf Deutsch „Abgrenzung“) von Software-Komponenten. Wie diese zu erfolgen hat, legt die Norm nicht fest, was zu vielen Diskussionen führt. Finden Sie hier Antworten auf häufige Fragen.  Inhaltsübersicht Was sind die Ziele der Segregation? » Segregation: Ist sie wirklich verlangt? » Wie erreicht man Segregation? » Welche Fehler sollten…

Weiterlesen