Begriffe und Definitionen zur Software für Medizinprodukte – IEC 62304 & FDA (Teil 2)

Dieser Artikel ist Teil unserer Reihe zur IEC 62304, die sich darauf konzentriert, die Norm zu verstehen und zu erläutern, wie sie bei der Entwicklung von Software für Medizinprodukte ordnungsgemäß umgesetzt werden kann.

Vorherige Artikel:

Dies ist der zweite Teil unserer Betrachtung der in IEC 62304 definierten Begriffe. In diesem Artikel werden wir die folgenden Konzepte behandeln:

ARCHITEKTUR
DETAILLIERTE SOFTWARE-ENTWICKLUNG
SYSTEM & SOFTWARE-SYSTEM
SOUP/OTS
RÜCKVERFOLGBARKEIT
PRODUKTLEBENSZYKLUS

Falls Sie noch kein eigenes Exemplar der IEC 62304 besitzen, können Sie es zu einem sehr günstigen Preis bei www.evs.ee, dem estnischen Zentrum für Normung und Akkreditierung, erwerben.

(Wir empfehlen die Wahl der PDF-Mehrbenutzerlizenz. Sie ist viel einfacher zugänglich und lesbar, ohne dass zusätzliche Software mit Plugins zum Urheberrechtsschutz erforderlich ist.)

Den offiziellen Wortlaut der meisten Begriffe und Definitionen finden Sie auch auf der ISO-Website.

Das Verständnis des Begriffs bringt Sie weiter

Im Laufe meiner Beratertätigkeit bin ich oft auf Situationen gestoßen, in denen sich Teams nicht über die in den von ihnen befolgten Normen verwendete Terminologie einig waren. Dies führt in der Regel zu wiederkehrenden Diskussionen darüber, ob interne SOPs tatsächlich den Normen entsprechen oder ob die in internen Prozessen verwendeten Begriffe wirklich mit denen übereinstimmen, die in den Normen beschrieben sind.

Es ist wichtig, sich vor Augen zu halten, dass sich alle ISO- und IEC-Normen im Laufe der Zeit weiterentwickelt haben; sie wurden nicht alle auf einmal erstellt. Aus diesem Grund werden Sie natürlich einige Abweichungen zwischen ihnen feststellen. Wichtiger als die Suche nach der „perfekten“ Definition eines Begriffs ist es, zu entscheiden, wie Ihre Organisation ihn interpretieren wird, diese Interpretation zu dokumentieren und sie konsequent anzuwenden.

Durch klar definierte Begriffe und Definitionen kann Ihre Organisation diese prozessübergreifend einheitlich verwenden. Außerdem lassen sie sich bei Bedarf viel einfacher anpassen oder aktualisieren, was sicherstellt, dass alle dieselbe Sprache sprechen, und dazu beiträgt, Verwirrung bei Audits zu vermeiden.

Nachfolgend finden Sie die zweite Reihe von Begriffen und Definitionen, die wir bei QMLogic verwenden, wenn wir Kunden bei der Entwicklung ihrer internen Verfahren unterstützen. Diese basieren nicht nur auf unserer Erfahrung mit der Prozessgestaltung nach IEC 62304, sondern auch auf unserer Teilnahme an zahlreichen Audits und unserer Arbeit an Kundenbefundberichten sowie CAPA-Korrekturmaßnahmen.

Architektur und architektonisches Design in der IEC 62304

Der Begriff Architektur ist für viele Entwickler selbsterklärend, und auch die Norm IEC 62304 geht im Abschnitt „Begriffe und Definitionen“ nicht ausführlich darauf ein. Sie beschreibt ihn lediglich als Organisationsstruktur eines Systems oder einer Komponente.

Trotz seiner scheinbaren Einfachheit verursacht er in Organisationen viel Ärger, vor allem in Bezug auf die Rückverfolgbarkeit oder die Verbindungen zu verschiedenen damit verbundenen Aktivitäten.

Wenn Sie die Norm IEC 62304 weiterlesen, werden Sie diesem Begriff an vielen Stellen begegnen, und die definierten Anforderungen an die Architektur werden die tatsächlich erwartete Bedeutung offenbaren. Darüber hinaus werden Sie feststellen, dass die Norm zwischen Architektur und Architekturdesign unterscheidet.

Und ohne ein angemessenes Verständnis dieser Unterscheidung könnten Sie Schwierigkeiten haben, die Norm einzuhalten.

Architekturdesign

Architekturdesign ist eine Aktivität. Es ist das, was Softwarearchitekten oder Entwickler im Allgemeinen regelmäßig in bestimmten Phasen des Designs und der Entwicklung tun. Im Gegensatz dazu ist das Ergebnis dieser Aktivität die Architektur selbst.

Während des gesamten Design- und Entwicklungsprozesses werden Sie Softwareanforderungen in der Architektur abbilden, Schnittstellen zwischen Softwarekomponenten definieren und SOUP/OTS-Komponenten (siehe nächstes Kapitel) identifizieren, um diese in das gesamte Softwaresystem zu integrieren.

All diese Schritte sind Teil des Software-Designs – des Prozesses, in dem die Struktur, die Komponenten und die Schnittstellen der Software definiert werden, um die festgelegten Anforderungen zu erfüllen.

Alles, was aus diesen Aktivitäten resultiert, wird dann als Architektur dokumentiert.

Softwarearchitektur

Ein häufiger Fehler – und eine häufige Quelle von Schwierigkeiten für Entwicklungsteams – ist es, Softwarearchitektur als nichts weiter als ein grafisches Diagramm zu betrachten. Ein Bild allein kann jedoch nicht alle Aktivitäten und Ergebnisse des Architekturdesigns erfassen, wie zuvor definiert.

IEC 62304, Abschnitt 5.3.6, besagt, dass eine Verifizierung der Softwarearchitektur durchgeführt und dokumentiert werden sollte, um sicherzustellen, dass alle Softwareanforderungen in der Gesamtarchitektur angemessen berücksichtigt werden und dass die Gesamtarchitektur die Schnittstellen zwischen den Komponenten unterstützt. Ein solches Maß an Verifizierung ist allein anhand eines Bildes nicht möglich und würde ein detailliertes Bild erfordern.

Daher ist es am besten, sich die Softwarearchitektur als ein lebendiges Dokument vorzustellen, mit dem Entwickler aktiv arbeiten und das sie regelmäßig aktualisieren.

Dieses Dokument sollte in der Regel Folgendes enthalten:

Ein grafisches Diagramm, das die Beziehungen zwischen den Komponenten darstellt
Eine Beschreibung, die erklärt, was das Diagramm darstellt
Eine Liste der Software-Elemente
Eine Liste externer Softwarekomponenten, auch bekannt als SOUP/OTS
Definierte Architekturansichten und Detailebenen

Was meine ich mit Architekturansicht oder Detailebene?

Es ist wichtig, Softwarearchitektur als eine Reihe von Diagrammen und Beschreibungen zu verstehen, nicht nur als eine einzelne Visualisierung. Jedes Diagramm kann je nach dem, was es darstellt, einen anderen Detaillierungsgrad aufweisen.

Beispielsweise könnte ein Diagramm eine Schnittstelle zu einer Hardwarekomponente veranschaulichen, ein anderes könnte zeigen, wie sensible Daten in der Datenbank getrennt werden, und wieder ein anderes könnte beschreiben, wie die Kommunikation verschlüsselt wird. Jedes dieser Diagramme behandelt unterschiedliche Anforderungen auf dem erforderlichen Detaillierungsgrad.

Bei QMLogic sind wir große Fans der FDA-Leitfäden, da sie oft einen klareren Einblick in die regulatorischen Erwartungen bieten. Wir empfehlen, die FDA-Leitlinie „Content of Premarket Submissions for Device Software Functions” (14. Juni 2023) zu lesen, insbesondere Abschnitt E: System- und Softwarearchitekturdiagramm.

Software-Detailentwurf in IEC 62304

Sobald wir verstanden haben, dass Softwarearchitektur auf verschiedenen Detailebenen existieren kann, wird es einfacher, einen weiteren Begriff aus der Norm zu begreifen – Software-Detailentwurf.

Obwohl die IEC 62304 den Begriff Software-Design nicht klar definiert, zeigt Kapitel 5.4, das sich auf dieses Thema konzentriert, dass man die gleichen Prinzipien wie bei der Software-Architektur anwenden kann, nur mit größerer Tiefe und Präzision. Mit anderen Worten: Software-Detailentwurf kann als detailliertere Ansicht der Architektur für eine bestimmte Softwarekomponente betrachtet werden.

Versuchen Sie also nicht, Software-Architektur und Software-Detailentwurf strikt voneinander zu trennen. Sie stellen unterschiedliche Detailebenen innerhalb desselben Konzepts dar, und es ist völlig akzeptabel, beide in einem einzigen Dokument zu beschreiben.

Weitere Hinweise finden sich wiederum im Dokument „Content of Premarket Submissions for Device Software Functions” (14. Juni 2023), in dem die FDA dieses Dokument als SDS (Software Design Specification) bezeichnet.

Abbildung 1: Software Design Specification gemäß Definition der FDA

Pflege des detaillierten Software-Entwurfs – Auswirkungen auf die FDA und die Cybersicherheit

Gemäß IEC 62304 ist ein Dokument zum detaillierten Software-Entwurf formal nur für Systeme der Software-Sicherheitsklasse C vorgeschrieben (wir behandeln dieses Thema ausführlicher in unserem Artikel „How to Start with the IEC 62304 Standard Implementation“). Wir empfehlen jedoch aus mehreren anderen wichtigen Gründen dringend, ein solches Dokument zu führen.

Erstens kann die FDA dieses Dokument im Rahmen eines Zulassungsantrags oder einer FDA-Inspektion anfordern.

Zweitens definiert die IEC 62304 den erforderlichen Umfang der technischen Dokumentation in erster Linie aus Sicht der Produktsicherheit. In der heutigen Welt vernetzter Geräte und cloudbasierter Lösungen ist jedoch die Cybersicherheit ebenso entscheidend geworden, und das Software-Design spielt heute eine bedeutendere Rolle für die Cybersicherheit als zuvor.

Cybersicherheitsnormen wie IEC 81001-5-1 verlangen ausdrücklich Software-Design-Aktivitäten, wie sie in den folgenden Auszügen aus der Norm beschrieben sind.

Abbildung 2: IEC 81001-5-1: Software-Architekturdesign

Abbildung 3: IEC 81001-5-1: Software-Design

Softwaresystem, System und Lösungen

Die Bedeutung von Softwaresystem ist recht einfach; sie bezieht sich auf eine Sammlung von Software-Elementen (siehe Teil 1 dieser Reihe für die Definition von „Element“).

Es ist jedoch wichtig, sich daran zu erinnern, dass IEC 62304 auch ein System definiert. Die Norm beschreibt es als eine Kombination von interagierenden Elementen wie Prozessen, Hardware, Software und Menschen.

Während wir Prozesse und Personen vorerst außer Acht lassen können, sollten Sie die Hardware, Datenspeicher, Cloud-Umgebung oder Kommunikationsinfrastruktur, die mit Ihren Softwareprodukten verbunden sind, nicht übersehen.

Meiner Erfahrung nach sind diese Schnittstellen für Entwickler, die an eingebetteter Software arbeiten, eher offensichtlich, werden jedoch bei der übergeordneten Entwicklung einer eigenständigen Medizinprodukt-Software oft übersehen.

Warum ist das wichtig? Weil die Leistung, Verfügbarkeit und Sicherheit Ihres Softwareprodukts durch das System, in dem es betrieben wird, beeinflusst werden können. Deshalb ist es wichtig, bei der Durchführung von Tests, Risikomanagement oder Cybersicherheitsmaßnahmen das gesamte System zu betrachten, nicht nur das Softwaresystem.

Möglicherweise stoßen Sie auch auf den Begriff Lösung. Dieser Begriff ist in der Norm nicht formal definiert und kann unterschiedlich verwendet werden. Er kann sich auf dasselbe Konzept wie ein System beziehen, auf eine Sammlung intern definierter Systeme oder sogar auf eine Gruppe verschiedener Medizinprodukte.

Sie ersparen sich viel Verwirrung und Nacharbeit, wenn Sie intern definieren, was Ihre Organisation unter einer „Lösung“ versteht.

SOUP/OTS im Software-Lebenszyklus

SOUP steht für Software of Unknown Provenance
OTS steht für Off-the-Shelf Software

Im Internet wird viel darüber diskutiert, ob SOUP und OTS dasselbe sind oder sich unterscheiden. Einfach ausgedrückt: Nein, in der Praxis gibt es für Sie praktisch keinen Unterschied.

Beide Begriffe beziehen sich auf Softwarekomponenten, die:

ursprünglich nicht als Teil eines Medizinprodukts entwickelt wurden und
über keine vollständige technische Dokumentation verfügen

Der einzige feine Unterschied besteht darin, dass SOUP theoretisch Software sein könnte, die zuvor von Ihrer eigenen Organisation entwickelt wurde, während OTS typischerweise aus einer externen Quelle stammt.

In der Realität bezieht sich SOUP oder OTS jedoch in 99,9 % der Fälle auf externe Software, die in Ihr Produkt integriert ist, und nicht auf etwas, das Ihr Team zuvor entwickelt hat. Diese Unterscheidung hat kaum praktische Auswirkungen darauf, wie Sie SOUP/OTS verwalten, außer vielleicht im Bereich der Cybersicherheit, wo intern entwickelte (selbst undokumentierte) Software als sicherer angesehen werden könnte als eine beliebige Bibliothek, die aus dem Internet heruntergeladen wurde.

Beispiele für SOUP/OTS sind:

Externe Bibliotheken, die in Ihrer Software verwendet werden
Betriebssysteme
Datenbanksysteme
Cloud-Lösungen
Backend- oder Frontend-Entwicklungsframeworks

Kurz gesagt sind SOUP und OTS Softwarekomponenten, die in der Norm IEC 62304 als „Software-Elemente“ bezeichnet werden und ihren Ursprung außerhalb Ihrer Organisation haben.

Warum ist es wichtig, SOUP/OTS zu identifizieren?

SOUP/OTS steht für externe Software, von der Ihr Produkt in Bezug auf Sicherheit, Wirksamkeit und Schutz abhängt. Deshalb ist es unerlässlich, diese Komponenten zu identifizieren und die mit ihnen verbundenen Risiken zu bewerten.

Sie sollten sich Fragen stellen wie:

Kann ich dieser Software vertrauen?
Wie kann ich damit verbundene potenzielle Gefahren minimieren?
Was würde passieren, wenn die SOUP/OTS nicht mehr funktionieren würde?
Ist sie vollständig mit unserem Softwaresystem kompatibel?
Könnte sie Sicherheitslücken oder sogar absichtliche Hintertüren enthalten?

Rückverfolgbarkeit und IEC 62304

Der Begriff Rückverfolgbarkeit ist in der Norm etwas kryptisch definiert, und seine Auslegung sowie praktische Anwendung sind nicht immer eindeutig. IEC 62304 definiert ihn als „den Grad, in dem eine Beziehung zwischen zwei oder mehr Produkten des Entwicklungsprozesses hergestellt werden kann.“

Hier beziehen sich „Produkte“ nicht auf Ihr Medizinprodukt selbst, sondern auf jedes Ergebnis, jede während Ihrer Entwicklungsaktivitäten erzeugte Ausgabe. Dazu gehören Design Controls wie Anforderungen, Architektur, Risikokontrollmaßnahmen und andere zugehörige Dokumente.

In der Praxis bedeutet dies, dass Sie über ein logisches System verfügen sollten, das Ihre Dokumente und die darin enthaltenen Informationen miteinander verknüpft und sicherstellt, dass alles konsistent und widerspruchsfrei bleibt.

Eine gängige Form der Rückverfolgbarkeit, die in den meisten Organisationen verwendet wird, ist die Verknüpfung zwischen Anforderungen, Risikokontrollmaßnahmen, Design und Verifizierung. Vereinfacht ausgedrückt kann dies etwa so aussehen:

Design Controls Traceability (DE) Abbildung 4: Design Controls Traceability

Die Definition von Rückverfolgbarkeit erwähnt jedoch auch, dass sie die Architektur umfasst. Dies führt uns zurück zu den früheren Kapiteln, in denen wir erörtert haben, was Architektur eigentlich bedeutet, und dieses Verständnis hilft zu klären, wie Rückverfolgbarkeit innerhalb der Architektur selbst angewendet wird.

Wie bereits erwähnt, ist Architektur mehr als nur ein grafisches Diagramm; sie ist ein umfassendes Dokument, das Beschreibungen enthält und auch Verknüpfungen (Rückverfolgbarkeit) zu spezifischen Anforderungen enthalten kann.

Warum ist Rückverfolgbarkeit hilfreich?

Klare Verbindungen zwischen Anforderungen und Architektur tragen dazu bei, dass alle spezifischen Bedürfnisse, wie beispielsweise im Zusammenhang mit Interoperabilität oder Sicherheit, im Architekturentwurf angemessen berücksichtigt werden.

Schauen wir uns ein Beispiel an. Angenommen, es gibt eine Anforderung für den verschlüsselten Datenaustausch über Bluetooth zwischen einem peripheren IoT-Gerät und einer mobilen Anwendung.

Diese Anforderung sollte in der Softwarearchitektur sichtbar sein:

Die Architektur sollte das periphere IoT-Gerät widerspiegeln.
Der Datenaustausch zwischen dem peripheren IoT-Gerät und der mobilen App sollte dargestellt werden.
Die Verschlüsselungsanforderung sollte in der Architektur erwähnt werden.
Die implementierte Lösung sollte beschrieben werden, einschließlich Details zum Pairing- und Verschlüsselungsverhalten.

Mit einer solchen nachvollziehbaren Struktur können Sie, falls Ihr Vorgesetzter, ein externer Prüfer oder ein FDA-Prüfer fragt, wie Daten zwischen dem Peripheriegerät und dem mobilen Gerät ausgetauscht werden, ein vollständiges, transparentes und nachvollziehbares Bild präsentieren.

Produktlebenszyklus

Obwohl der Standard selbst den Begriff Lebenszyklus im Titel enthält, kommen wir erst jetzt zu diesem Begriff.

Während IEC 62304 eine klare Definition des Softwareentwicklungslebenszyklusmodells liefert, ist es ebenso wichtig, das umfassendere Konzept des Produktlebenszyklus zu verstehen.

Viele Unternehmen neigen dazu, den Produktlebenszyklus hauptsächlich mit Design- und Entwicklungsaktivitäten in Verbindung zu bringen.

In Wirklichkeit umfasst der Produktlebenszyklus jedoch die gesamte Lebensdauer eines Medizinprodukts, vom ersten Konzept bis hin zum Ende seiner Lebensdauer. Diese umfassendere Perspektive ist besonders wichtig für Software, bei der die Wartbarkeit eine zentrale und fortlaufende Rolle spielt.

Warum ist der Produktlebenszyklus wichtig?

Das Umfeld rund um Software für Medizinprodukte verändert sich ständig. Betriebssysteme entwickeln sich weiter, die Cloud-Infrastruktur wird aktualisiert, in Bibliotheken entstehen neue Sicherheitslücken, und die Softwarekomponenten, auf die Ihr Produkt angewiesen ist, können irgendwann

inkompatibel werden. All diese Faktoren müssen nach der Veröffentlichung Ihres Produkts überwacht und verwaltet werden.

Darüber hinaus unterliegen die Daten, die Ihre Software verarbeitet, während ihrer gesamten Nutzungsdauer gesetzlichen und datenschutzrechtlichen Anforderungen. Während der Auslaufphase oder End-of-Life-Phase ist es unerlässlich, definierte Prozesse zu haben, die sicherstellen, dass keine sensiblen medizinischen Daten mehr zugänglich sind oder unsachgemäß gespeichert werden, sobald das Produkt nicht mehr angeboten wird.

Fragen Sie sich:

Was passiert, wenn ein Benutzer Ihre Anwendung nicht mehr nutzt?
Erkennen Sie dieses Ereignis und verfügen Sie über Verfahren, um die Daten dieses Benutzers zu identifizieren und zu löschen?
Können Sie bestätigen, dass alle nicht mehr genutzten Kundendaten sicher entfernt wurden?
Gibt es bekannte neue Sicherheitslücken in den von mir verwendeten Softwarekomponenten?
Ist mein Produkt mit allen aktuellen Betriebssystemversionen kompatibel?
Gibt es Probleme in der App oder im Produkt, die während der Tests nicht entdeckt wurden, aber im Produktivbetrieb auftreten?

Diese Fragen verdeutlichen, warum der Produktlebenszyklus über Design und Entwicklung hinausgeht.

Im heutigen digitalen Zeitalter werden solche Überlegungen zum Lebenszyklus zunehmend von Prüfern und Aufsichtsbehörden, einschließlich der FDA, geprüft.