Die Hersteller medizinischer Software müssen die gesetzlichen Anforderungen an die Software-Komponenten erfüllen, um ihre Produkte „zulassen“ zu dürfen.
Dieser Artikel stellt diese Anforderungen vor und gibt 7 Tipps, wie diese schnell und einfach zu erfüllen sind.
1. Was Software-Komponenten sind
a) Definition
Die IEC 62304 definiert den Begriff Software-Komponente wie folgt:
jedes identifizierbare Teil eines Computerprogramms
Die englische Version der Norm spricht vom Software Item.
Damit umfassen Software-Komponenten alle Teile der Software, sowohl das Software-System selbst als auch alle Software-Einheiten (s. Abb. 1).
Lesen Sie hier, was Software-Einheiten (software units) sind, welche regulatorischen Anforderungen diese erfüllen müssen und wie das gelingt.
b) Beispiele
Zu den Software-Komponenten zählen auch Software-Module, ein Begriff, den die Leitlinie MDCG 2019-11 nutzt. SOUP sind ebenfalls Software-Komponenten, weil auch sie identifizierbare Teile eines Software-Systems sind.
Die IEC 62304 legt nicht fest, ob die Software-Komponenten logische und physische Komponenten sind.
- Eine logische Software-Komponente wäre z. B. ein Package oder ein Web-Assembly. UML-Klassen und UML-Komponentendiagramme modellieren logische Komponenten.
- Unter physischen Software-Komponenten versteht man hingegen Teile einer Software, die als Datei erkennbar sind, wie .dll-, .exe-, HEX- oder Skriptdateien.
2. Regulatorischen Anforderungen
a) Europa
MDR, IVDR
Die EU-Verordnungen wie MDR und IVDR stellen keine expliziten Anforderungen an Software-Komponenten. Aber sie fordern eine Software-Architektur. Eine Software-Architektur ist gemäß Definition die Zerlegung eines Software-Systems in Komponenten.
IEC 62304
Die harmonisierte Norm IEC 62304 verlangt ebenfalls eine Zerlegung in Software-Komponenten.
An SOUPs stellt sie weitere Anforderungen. Außerdem verpflichtet die Norm die Hersteller dazu,
- die Software-Komponenten in Software-Einheiten zu zerlegen (Kapitel 5.4),
- die Schnittstellen dieser Komponenten zu spezifizieren,
- zu überprüfen, ob die Software-Komponenten sich spezifikationsgemäß verhalten,
- die Software-Komponenten stückweise zu integrieren und deren Zusammenspiel zu testen (Kapitel 5.7; Integrationstests).
b) USA
Die FDA formuliert ihre Anforderungen an Software v. a. in ihrer Leitlinie General Principles of Software Validation. Darin unterscheidet sie die Begriffe unit, component und module nicht. Sie fordert aber von den Herstellern
- eine Software-Architektur mit einer „modular structure“,
- das „unit (module or component) level testing“ und
- den besonderen Umgang mit Off-the-shelf-Komponenten. Dazu hat sie weitere Leitlinien veröffentlicht.
Die Leitlinie Content of the premarket submission gibt vor, welche Unterlagen Hersteller einreichen müssen. Darin macht die FDA auch Vorgaben für die Software-Architektur (z. B. „detailed diagrams of the modules“).
3. Sieben Tipps für die Praxis
Tipp 1: Wirkliche Komponenten festlegen
Eine Komponente ist eine logische oder physikalische Einheit. Es reicht nicht aus, in Powerpoint um eine willkürliche Auswahl an Klassen einen Rahmen zu malen und dies „Komponente“ zu nennen.
Tipp 2: Komponenten nach funktionalen Überlegungen festlegen
Wenn die Software-Anforderungen vorliegen, können Sie beginnen, diese Anforderungen nach funktionalen Aspekten zu gruppieren. Das hilft, um die Komponenten auch nach funktionalen Überlegungen zu bilden. Eine Komponente sollte genau eine Aufgabe erfüllen.
Tipp 3: Die Schnittstellen früh und präzise festlegen
Legen Sie die Architektur und damit die Software-Komponenten und deren Schnittstellen in einer frühen Entwicklungsphase fest. Denn nur dann gelingt es, unterschiedliche Teams parallel arbeiten zu lassen.
Ein Beispiel für Komponenten sind Microservices. Bei diesen nutzen unterschiedliche Entwicklungsteams sogar verschiedene Technologien und Programmiersprachen, wenn sie gegen die vorgegebenen Schnittstellen programmieren.
Tipp 4: Tools für die Definition und das Testen von Schnittstellen nutzen
Beschreiben Sie die Schnittstellen als API. Bei webbasierten Anwendungen sind Werkzeuge wie OpenAPI, der Nachfolger von Swagger API, hilfreich.
Tipp 5: Gute Kapselung sicherstellen
Software-Komponenten sollten Funktionalitäten kapseln und nur über wohldefinierte Schnittstellen zur Verfügung stellen. Je schwächer Software-Komponenten voneinander abhängen („weak coupling“), desto besser ist die Software zu warten und zu testen.
Was dabei hilft
Eine schwache Kopplung von Komponenten erreichen Sie, indem Sie
- nur wenige Methoden und Variablen dieser Komponente öffentlich machen,
- die Anzahl der Übergabeparameter von Methoden minimieren,
- Vererbung über Komponentengrenzen hinweg vermeiden und
- Methoden durch Interfaces abstrahieren.
Was dabei schadet
Folgende Vorgehensweisen sind schädlich:
- Bei Klassen, Methoden und Funktionen möglichst oft das Schlüsselwort „public“ wählen (schließlich soll doch jeder auf die großartigen Funktionen zugreifen können 😉)
- Methoden mit möglichst vielen Übergabeparametern entwerfen
- Viele globale Variable definieren, um von überall auf diese Werte zugreifen zu können
- Vererbungsbeziehungen über Komponentengrenzen hinweg definieren
- Fehler über Komponentengrenzen werfen
Tipp 6: Existierende Komponenten nutzen
Am schnellsten ist eine Software-Komponente verfügbar, wenn sie gar nicht erst entwickelt werden muss. Daher ist es hilfreich, bereits bewährte Komponenten wie Bibliotheken und andere SOUP/OTS wiederzuverwenden.
Hersteller, die für verschiedene Medizinprodukte auf bewährte Komponenten, Frameworks bzw. Plattformen zurückgreifen können, sind in der Entwicklung schneller.
Tipp 7: Komponenten automatisiert testen
Im Extremfall verfolgen Hersteller einen Test-Driven Development-Ansatz. Zumindest sollten sie von Anfang an alle Schnittstellen von allen Komponenten automatisiert testen und diese Tests als Regressionstests bei allen Änderungen wiederholen.
4. Fazit und Zusammenfassung
Die regulatorischen Anforderungen an den Umgang mit Software-Komponenten sind weltweit relativ homogen. Eine professionelle Software-Entwicklung wird diese Anforderungen erfüllen. Dies setzt voraus, dass die Hersteller
- die Software-Architektur früh und präzise festlegen,
- dabei die Komponenten identifizieren sowie deren Schnittstellen spezifizieren und
- mit Software-Tests sicherstellen, dass die Komponenten dieser Schnittstelle-Spezifikation genügen.
Eigentlich kein Hexenwerk. Aber die Praxis spiegeln sich die Wirrungen bei der Entwicklung und Kompromisse bei der Exzellenz wider. Das darf nicht sein, denn eine professionelle Entwicklung ist nicht nur effizient: Sie führt zu Software einer hohen Qualität und damit zu sichereren Medizinprodukten.
Unterstützung
Das Johner Institut unterstützt Sie dabei, schlanke und normenkonforme Software-Akten zu erstellen und Ihre Medizinprodukte schnell und sicher in den Markt zu bringen.
Im Kompaktseminar „Medizinische Software“ erwerben Sie die vorgeschriebenen Kompetenzen. Sie lernen die gesetzlichen Anforderungen an die Software-Entwicklung kennen und erfüllen.
Mit dem Auditgarant lernen Sie 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 zusätzlich viel Arbeit ab.
