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.
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.
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.
Die Software-Architektur ist die Zerlegung eines Software-Systems in Komponenten und die Spezifikation der Schnittstellen zwischen diesen Komponenten.
Eine anschauliche Definition stammt von Martin Fowler:
Die Menge aller wichtigen und schwer änderbaren Entscheidungen
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.
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.
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).
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.
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.
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.
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.
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).
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.
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“.
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.
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.
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.
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
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.
Der Artikel zur Dokumentation der Software-Architektur stellt Ihnen eine bewährte Kapitelstruktur vor.
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.
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.
Nutzen Sie die Unterstützung des Johner Instituts:
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.
„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
Eine Schichtenarchitektur ist ein Architekturstil, der häufig bei Software-Systemen Anwendung findet. Vielen Herstellern sind die Nachteile eine mehrschichtigen Architektur und eines Denkens in Layern nicht bewusst.
Die Risikoanalyse bei Software unterscheidet sich: Software selbst kann keine Schäden verursachen. Dies geschieht immer via Hardware oder Menschen. Doch das heißt nicht, dass es keiner Risikoanalyse bei Software bedarf. Im Gegenteil!
Der Begriff der Software-Einheit (englisch: Software Unit) entstammt der IEC 62304. Vielen Herstellern unterlaufen beim Spezifizieren und Testen dieser Software-Einheiten Fehler. Diese Artikel gibt Ihnen Tipps, diese zu vermeiden.
WeiterlesenDie 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.
WeiterlesenDie Software-Architektur Dokumentation dient vor allem diesen Zielen:
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…
WeiterlesenAuf 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.
Viele Medizinproduktehersteller nutzen für die Entwicklung ihrer Produkte Engineering Dienstleister. Dieser Beitrag verrät Ihnen, auf was Sie dabei achten sollten. Übersicht Gründe für und gegen das Auslagern » Regulatorische Sicht » Was Sie beachten sollten »
Weiterlesen