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.


PESS: Programmierbare elektronische Subsysteme

Die IEC 60601-1 definiert ein PESS, ein programmierbares elektronisches Subsystem, als System, das auf einer oder mehreren zentralen Prozessoreinheiten beruht, einschließlich deren Software und Schnittstellen. Die Norm verrät nicht, was sie unter System versteht, es ist in diesem Kontext eine Komponente des Medizinprodukts. Dafür stellt die IEC 60601-1 konkrete Anforderungen an die PESS.

Weiterlesen

UML Unified Modeling Language: Nicht nur für Software-Architekturen

Die UML, die Unified Modeling Language, ist eine standardisierte Sprache, mit der sich Software, aber auch ganze Systeme beschreiben lassen. Durch die wenigen aber genau definierten Notationselemente der UML sind Hersteller befähigt, Sachverhalten eindeutig und präzise zu beschreiben und so Anforderungen z.B. der IEC 60601-1 und IEC 62304 zu erfüllen.  Inhaltsübersicht Modellierung der Wirklichkeit » Modellierung von…

Weiterlesen

Design Review ungleich Review des Designs!?

Auf die Frage, was ein Design Review sei, bekommt man häufig unterschiedliche Antworten — abhängig davon, ob man einen Entwickler oder einen Qualitätsmanager fragt. Genau diese unterschiedlichen Sichten können im Audit zum Problem werden.  Inhaltsübersicht Design Review: Begriffsdefinition » Ziele des Design Reviews » Regulatorische Anforderungen » Design Review planen » Design Review auditieren »

Weiterlesen