{"id":8419,"date":"2025-01-30T16:17:09","date_gmt":"2025-01-30T15:17:09","guid":{"rendered":"http:\/\/www.johner-institut.de\/blog\/?p=8419"},"modified":"2025-02-01T08:58:21","modified_gmt":"2025-02-01T07:58:21","slug":"software-schnittstellen-beschreibung-konform-iec-62304","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iec-62304-medizinische-software\/software-schnittstellen-beschreibung-konform-iec-62304\/","title":{"rendered":"Software-Schnittstellen konform IEC 62304"},"content":{"rendered":"\n

Interne Software-Schnittstellen <\/strong>sind notwendig, um Software-Komponenten innerhalb eines Software-Systems zu verbinden. Externe Software-Schnittstellen <\/strong>sind die Voraussetzung daf\u00fcr, dass das Software-System mit anderen Systemen kommunizieren kann.<\/p>\n\n\n\n

Dieser Artikel beschreibt, wie Sie Software-Schnittstellen gesetzeskonform und praxisnah dokumentieren k\u00f6nnen.<\/p>\n\n\n\n\n\n\n\n

1. Interne vs. externe Software-Schnittstellen<\/h2>\n\n\n\n

1.1 \u00dcbersicht<\/h3>\n\n\n\n

Medizinprodukte, gleich ob Standalone-Software oder physische Ger\u00e4te, bestehen aus Komponenten. Damit nutzt ein Produkt nicht nur externe Schnittstellen, sondern auch interne, n\u00e4mlich zwischen den einzelnen Komponenten.<\/p>\n\n\n\n

1.2 Sonderfall: interne = externe Schnittstelle<\/h3>\n\n\n\n

Zerlegt man das Software-System in Komponenten, gilt es im n\u00e4chsten Schritt, diese Komponenten und deren Schnittstellen zu spezifizieren. Dabei kann und muss es vorkommen, dass die Schnittstellen der \u00e4u\u00dferen Komponente gleichzeitig die der inneren Komponenten sind.<\/p>\n\n\n\n

\"Komponenten-interne-externe-Schnittstellen\"<\/a>
Abb 1.: Externe Schnittstellen sind immer auch interne Schnittstellen (hier mit orangenen Kreisen markiert). Umgekehrt haben interne Schnittstellen nicht immer ein externes Pendant.<\/figcaption><\/figure>\n\n\n\n

Beispiel<\/strong>: Die GUI eines Medizinger\u00e4ts wird gleichzeitig die GUI der Komponente sein, auf der die \u201eSoftware-GUI\u201c l\u00e4uft. Auch \u201eDaten-Schnittstellen\u201c werden direkt zu einer Komponente durchgereicht, welche diese Daten-Schnittstelle implementiert.<\/p>\n\n\n\n

<\/path><\/path><\/g><\/svg><\/div>Tipp<\/span><\/div>\n

Spezifizieren Sie diese Schnittstellen nicht redundant, sondern verweisen Sie in der Komponenten-Spezifikation auf die entsprechende Spezifikation des \u00fcbergeordneten Medizinprodukts bzw. der \u00fcbergeordneten Komponente.<\/p>\n<\/div>\n\n\n\n

1.3 Sonderfall: Internet als interne Software-Schnittstelle<\/h3>\n\n\n\n

Ob eine \u201eInternet-Schnittstelle\u201c intern oder extern ist, h\u00e4ngt davon ab, was man als System (z. B. als Medizinprodukt) definiert.<\/p>\n\n\n\n

Wenn Sie beispielsweise das Gesamtsystem aus einer Mobile Medical App<\/a> und der zugeh\u00f6rigen Server-Software als ein<\/strong> Medizinprodukt <\/strong>und zugleich die Gesamtheit aller Software als ein Software-System <\/strong>definieren, dann ist das Internet eine interne<\/strong>(!)\u00a0Software-Schnittstelle, die zwei Komponenten des Software-Systems verbindet: die Medical-App-Software-Komponente mit der Server-Software-Komponente.<\/p>\n\n\n\n

\"Internet:
Abb. 2: Gesamtsystem aus einer Mobile Medical App und einer Server-Software, die \u00fcber das Internet verbunden sind.<\/figcaption><\/figure>\n\n\n\n
<\/path><\/svg><\/div>Vorsicht mit dieser Aufteilung<\/span><\/div>\n

Wir raten davon ab, das Software-System<\/a>\u00a0als Gesamtheit aller Software zu definieren. Ein\u00a0Software-System sollte immer an den Grenzen der jeweiligen Prozessor-\/Speichereinheit enden. In obigem Beispiel h\u00e4tte man somit zwei Software-Systeme: zum einen die App und zum anderen die Server-Software. Dann sind die Schnittstellen zum Internet jeweils externe Software-Schnittstellen.<\/p>\n\n\n\n

Diese Aufteilung empfehlen wir \u00fcbrigens unabh\u00e4ngig davon, ob Sie beide Systeme zu einem Medizinprodukt z\u00e4hlen oder nicht.<\/p>\n<\/div>\n\n\n\n

2. Regulatorische Anforderungen  <\/h2>\n\n\n\n

Die IEC 62304<\/strong> verlangt in Kapitel 5.3.2, dass die Hersteller die Software-Schnittstellen zwischen den Software-Komponenten dokumentieren.\u00a0Eine nahezu identische Forderung findet sich im Kapitel 5.4.3, die ebenfalls die \u201eEntwicklung eines detaillierten Designs fu\u0308r Schnittstellen\u201c<\/cite> fordert.<\/p>\n\n\n\n

Beide Kapitel verlangen die Dokumentation der Software-Schnittstellen, legen aber nicht fest, wie diese Software-Schnittstellen zu beschreiben\/spezifizieren sind.<\/p>\n\n\n\n

\u00c4hnlich unkonkret fordert\u00a0die\u00a0FDA im Software Validation Guidance<\/strong>\u00a0eine\u00a0\u201edefinition of all external and user interfaces, as well as any internal software-to-system\u00a0interfaces<\/em>\u201c.<\/p>\n\n\n\n

Wenn Sie die Schnittstellen Ihrer Software wie nachfolgend vorgeschlagen dokumentieren, erf\u00fcllen Sie die regulatorischen Anforderungen.<\/p>\n\n\n\n

3. Dokumentation von Software-Schnittstellen<\/h2>\n\n\n\n

Spezifikationen sollten das spezifizierte Objekt als Blackbox beschreiben, d. h. \u00fcber dessen Schnittstellen. Das gilt f\u00fcr Produkte bzw. Systeme (z. B. physische Ger\u00e4te mit Medizinger\u00e4ten (PEMS) oder Standalone-Software-Systeme) ebenso wie f\u00fcr\u00a0Komponenten solcher Systeme, z. B. Programmierbare Elektrische Subsysteme\u00a0(PESS<\/a>) oder Software-Komponenten.\u00a0<\/p>\n\n\n\n

Software und Software-Komponenten verf\u00fcgen \u00fcber maximal drei Schnittstellentypen:<\/p>\n\n\n\n

    \n
  1. Benutzer-System-Schnittstellen (User Interface, GUI)<\/li>\n\n\n\n
  2. System-System-Schnittstellen (Datenschnittstellen wie API, BUS-Systeme, Sensoren, Aktoren, Webservices)<\/li>\n\n\n\n
  3. Schnittstelle zur Laufzeitumgebung<\/li>\n<\/ol>\n\n\n\n

    Schritt 1: Software-Schnittstellen identifizieren<\/h3>\n\n\n\n

    Wie granular Sie die Software-Schnittstellen spezifizieren m\u00fcssen, legen die Normen (wie die IEC 62304) nicht fest. Sie m\u00fcssen die Schnittstellen aber dokumentieren.<\/p>\n\n\n\n

    Der erste und einfachste Schritt besteht darin, die Schnittstellen \u00fcberhaupt in der Software-Architektur kenntlich zu machen. Hier empfehlen sich Komponenten-Diagramme und die Lollipop-Notation (siehe Abb. 3).\u00a0<\/p>\n\n\n\n

    \"Exemplarisches
    Abb. 3: Exemplarisches UML-Komponentendiagramm mit Lollipops, die die Software-Schnittstellen identifizieren.<\/figcaption><\/figure>\n\n\n\n

    Mit Lollipops k\u00f6nnen Sie besonders gut visualisieren, welche Schnittstellen es gibt, welche Software-Komponenten die Schnittstellen implementieren und welche Komponenten die Schnittstellen anderer Komponenten nutzen.<\/p>\n\n\n\n

    Schritt 2: Die identifizierten Software-Schnittstellen spezifizieren<\/h3>\n\n\n\n

    Eine blo\u00dfe Nennung der Schnittstellen ist nicht ausreichend, um Normenkonformit\u00e4t und den eigentlichen Sinn dieser Dokumentation zu erreichen, also dem Programmier-Team und den Personen, die die Komponenten testen, ausreichend Informationen f\u00fcr deren Arbeit bereitzustellen.<\/p>\n\n\n\n

    Programmierschnittstellen API<\/h4>\n\n\n\n

    Daher besteht der n\u00e4chste Schritt darin, die API der Schnittstellen zu spezifizieren. Erst damit legen Sie wirklich die Anforderungen an die Komponenten fest. Die API beschreibt:<\/p>\n\n\n\n

      \n
    1. Namen und Zweck der nach au\u00dfen verf\u00fcgbaren Funktionen\/Methoden<\/li>\n\n\n\n
    2. Name, Bedeutung und Wertebereiche von \u00dcbergabe- und R\u00fcckgabeparametern<\/li>\n\n\n\n
    3. Verhalten der Komponente bei Nutzung einer Funktion\/Methode. Dieses Verhalten kann sich nur \u00fcber eine Schnittstelle der Komponente zeigen.<\/li>\n<\/ol>\n\n\n\n

      Andere Schnittstellentypen<\/h4>\n\n\n\n

      Wenn Sie andere Software-Schnittstellen beschreiben m\u00fcssen, z. B.<\/p>\n\n\n\n