Die Systemarchitektur beschreibt, aus welchen Komponenten ein (Medizin)produkt zusammengesetzt ist und wie diese Komponenten über Schnittstellen miteinander in Beziehung stehen. Bei Standalone-Software fallen Systemarchitektur und Software-Architektur zusammen.
1. Dokumentation der Systemarchitektur
a) Notationssprache
Die Dokumentation sollte die einzelnen Komponenten und ihr Zusammenspiel erkennen lassen. Es hat sich bewährt, Standardnotationen wie UML bzw. SysML zu nutzen und nicht in PowerPoint mit undefinierten Notationselementen zu arbeiten.
Neben den Diagrammen mit den verschiedenen Sichten gilt es, die Schnittstellen der einzelnen Komponenten zu spezifizieren. Hier finden Sie Hinweise, wie Sie Interoperabilitätsanforderungen vollständig beschreiben können.
b) Aufteilung der Dokumentation in Systemarchitektur und Komponenten-Spezifikation
Bedarf es zweier Dokumente, nämlich einer Systemarchitektur und einer Komponenten-Spezifikation? Sollten diese beiden Dokumente zeitnah geschrieben werden? Von der gleichen Person?
Ob man die Systemarchitektur und Komponenten-Spezifikationen (Plural) in ein oder mehreren Dokumenten verfassen sollte, lässt sich nicht pauschal beantworten. Das hängt u. a. davon ab,
- wie viele Komponenten es gibt,
- wie umfangreich das Dokument werden würde,
- ob die Komponenten von einem oder mehreren unabhängigen Teams entwickelt werden,
- ob die Komponentenentwicklung im Unternehmen erfolgt oder ausgelagert wird.
Die Komponenten-Spezifikationen sollten zeitnah und immer unter Mitwirkung des System-Architekten bzw. der System-Architektin erfolgen. Schließlich sind sie es, die das zu entwickelnde System in Komponenten zerlegen. Sie beschreiben auch, wie diese Komponenten zu interagieren haben. D. h. sie legen fest, wie sich die Komponenten über ihre Schnittstellen im Sinne einer Blackbox verhalten. Und genau das ist eine Komponenten-Spezifikation.
Diese Überlegungen gelten übrigens unabhängig davon, ob man ein Medizingerät oder eine Standalone-Software entwickelt. Sie sind für PEMS genauso anwendbar wie für Software-Systeme. Im einen Fall bewegen wir uns eher im Dunstkreis der IEC 60601, im anderen Fall dem der IEC 62304.
2. Regulatorische Anforderungen an die Systemarchitektur
Es gibt einige regulatorischen Anforderungen an die Dokumentation von Systemarchitekturen.
a) Anforderungen von MDR und IVDR
Beispielsweise fordert die MDR (und analog die IVDR) in Anhang II:
Eine allgemeine Beschreibung der wichtigsten Funktionselemente des Produkts, z. B. Bestandteile/Komponenten (einschließlich Software, sofern zutreffend) […]. Dazu gehören gegebenenfalls gekennzeichnete bildliche Darstellungen (z. B. Diagramme, fotografische Bilder und Zeichnungen), in denen die wichtigsten Bestandteile/Komponenten eindeutig gekennzeichnet sind, einschließlich ausreichender Erläuterungen für das Verständnis der Zeichnungen und Diagramme;
b) Anforderungen der IEC 60601-1
Auch die IEC 60601-1 fordert, dass Medizinproduktehersteller die programmierbaren elektronischen Subsysteme (PESS) identifizieren, Anforderungen daran formulieren und deren Erfüllung verifizieren. Ohne eine dokumentierte Systemarchitektur sind diese Forderungen nicht zu erfüllen.
c) Anforderungen der FDA
Die Anforderungen der FDA hängen vom jeweiligen Zulassungsverfahren ab. Bereits bei den „510(k)-Zulassungen“ fordert die FDA in diesem Guidance-Dokument:
An overall description of the device design. A complete description of the device may be facilitated by the submission of engineering drawings or other figures. If the device consists of multiple components, a diagram identifying how the different components of the device system work together may be beneficial.
Das entspricht genau der Systemarchitektur.
d) Weitere regulatorische Anforderungen
Die ISO 14971 fordert nicht explizit eine dokumentierte Systemarchitektur. Aber diese ist eine notwendige Voraussetzung für eine Risikoanalyse und insbesondere für eine FMEA.
Eine geeignete Systemarchitektur dient also gleichzeitig der Risikobeherrschung.
Im Auditgarant finden Sie Videotrainings zu sicherheitskritischen Systemarchitekturen.
3. Vorgehen beim Erstellen der Systemarchitektur
a) Zerlegen der Systemarchitektur in Komponenten
Bei der Zerlegung von Systemen in Komponenten neigen manche Hersteller dazu, diese in die „Gewerke“ zu zerlegen, beispielsweise in Mechanik, Elektromechanik, Elektronik und Software (linke Seite in Abb. 3).
Viele Hersteller haben mit dieser Option keine guten Erfahrungen gemacht. Zum einen entspricht diese schichtartige Systemarchitektur (hoffentlich) nicht der Realität. Zum anderen führt diese „Lasagnen-Architektur“ dazu, dass man nicht konsequent in (funktionalen) Komponenten denkt (rechte Seite in Abb. 3).
Nur eine konsequent komponentenorientierte Systemarchitektur führt zu wartbaren, sicheren und testbaren Medizinprodukten und zu wiederverwendbaren Komponenten.
b) Zusammenspiel von Systemarchitektur und Software-Architektur
Bei Medizingeräten ist es nicht hilfreich, Software-Komponenten auf der ersten Ebene der Systemarchitektur zu modellieren. Ob das bei Fall ist, lässt sich leicht in der Software-Architektur erkennen.
Es gibt zwei Varianten, um zu definieren, was das Software-System ist.
Variante 1: Ein Software-System ist Teil eines PESS (oberer Teil in Abb. 4)
Wenn Sie ein Software-System als die Gesamtheit aller Software definieren, das in einem Speicher/Prozessor (und damit in einem PESS) läuft, sollte in der Systemarchitektur überhaupt keine Software zu sehen sein. (Es sei denn, dass zum System eine Standalone-Software zählt.) Man erkennt dann in der Systemarchitektur nur die Komponenten, von denen eine Untermenge PESS sind. In jeder PESS wiederum gibt es Software (also ein Software-System), für das es erneut Software-Anforderungen und eine Software-Architektur gibt und damit Software-Komponenten identifiziert werden. Aber letztere sieht man eben nicht in der Systemarchitektur.
Variante 2: Das Software-System ist die Gesamtheit aller Software (unterer Teil in Abb. 4)
Wenn man hingegen unter einem Software-System die Gesamtheit aller Software im Medizinprodukt versteht (diese Definition empfiehlt das Johner Institut meist nicht), dann hätte man auch hier eine „Lasagne-Architektur“ vorliegen. In anderen Worten: Der Hersteller hat keine Systemarchitektur erstellt, sondern eine Software-Architektur, eine Elektronik-Architektur und eine „Mechanik-Architektur“.
Es gibt aber keine gesetzlichen oder normativen Vorgaben, für welche Variante Sie sich entscheiden.
4. Fazit und Zusammenfassung
Auf eine Systemarchitektur können Hersteller von Medizinprodukten und IVD in der Regel nicht verzichten. Zum einen fordern Normen und Gesetze diese Systemarchitekturen; zum anderen sind sie die Voraussetzung für eine schnelle Entwicklung von sicheren, wartbaren und testbaren Medizinprodukten.
Daher sollten Hersteller sich Zeit nehmen und die Kompetenzen im Entwicklungsteam sicherstellen, um die bestmögliche Systemarchitektur zu entwickeln. Hier gilt der Gedanke von Konfuzius: Wer am Ende schnell sein will, muss am Anfang langsam gehen.
Das Team des Johner Instituts ist darauf spezialisiert, mit bzw. für Medizinproduktehersteller Systemarchitekturen zu erstellen und zu prüfen. Damit lassen sich
- Risiken durch das Medizinprodukt identifizieren und beherrschen,
- Schwierigkeiten im Audit und bei der Zulassung vermeiden,
- Systemarchitekturen schlank, präzise, aussagekräftig und normenkonform dokumentieren sowie
- Fehler frühzeitig finden und beheben und so teure Nachbesserungen und Projektverzug vermeiden.
Nehmen Sie Kontakt mit den Experten des Johner Instituts auf.
Änderungshistorie
- 2024-10-09: Artikel grundlegend überarbeitet, aktualisiert und neu strukturiert. Bilder überarbeitet und ergänzt.
- 2015-04-23: Erste Version veröffentlicht
