Blog des Johner Instituts:
Wissen zu medizinischer Software

Der Institutstag 2015 steht in den Startlöchern! Wie jedes Jahr werden wir am ersten Freitag im Juli — dieses Mal ist es der 03. Juli 2015 — unser akademisches Sommerfest feiern! Ein Tag für Geist, Körper und Seele!

Institutstag: Weshalb Sie teilnehmen sollten

Der Institutstag bietet Ihnen die Möglichkeit,

• einen wunderschönen Sommertag am Bodensee zu verbringen,
• mehr über das Thema medizinische Software zu lernen,
• spannende Menschen zu treffen wie potenzielle Kunden, Arbeitgeber und Mitarbeiter,
• an unserem kulturellen und kulinarische Highlight, abends im Konzil teilzunehmen.

Das Konzil Konstanz: Hier feiern wir abends (Bildquelle: Konstanz Tourismus)

Wie jedes Jahr werden sowohl der Institutstag als auch die Unterkünfte schnell ausgebucht sein. Melden Sie sich daher rasch an, sichern Sie sich rasch Ihre Quartier in Konstanz!

Zum Institutstag anmelden

Themenschwerpunkt

Dieses Jahr decken sich das Thema des Johner Instituts und des Institutstags besonders eng: Medizinische Software. Immer mehr unterstützt Software die Diagnose, Überwachung und Therapie von Patienten und wir damit zum Medizinprodukt. Wir untersuchen die Auswirkungen dieser Klassifizierung auf Hersteller und Betreiber und gehen dabei auch auf aktuelle Trends ein wie die Mobile Medical Apps.

Natürlich werden wir auch dieses Jahr gemeinsam feiern, dieses Mal wieder im Konstanzer Konzil. wir starten mit einem Apero auf der Terrasse, werden danach ein gemeinsames Menü genießen und die Studierenden des neunten Masterstudiengangs “IT im Gesundheitswesen” und des zweiten MBAs verabschieden. Wie immer von einem hochklassigen künstlerischen Programm umrahmt.

Unter Traceability versteht man die Nachvollziehbarkeit verschiedener Aktivitäten entlang des Entwicklungslebenszyklus. Die für Medizinprodukte spezifischen Normen wie die ISO 14971 und die IEC 62304 stellen teilweise konkrete Anforderungen an die Traceability.

Lesen Sie mehr

• zur Traceability und IEC 62304
• zur Traceability und ISO 14971
• zur Werkzeugunterstützung

Traceability und IEC 62304

Die IEC 62304 verlangt die Traceability u.a.

• von den System-Anforderungen zu den Software-Anforderungen
• von den Software-Anforderungen in die Software-Architektur
• vom detaillierten Design zur Software-Architektur
• von den Software-Systemtests zu den Software-Anforderungen

Traceability zwischen Software-Anforderungen und Software-Architektur

„Der Hersteller muss verifizieren und dokumentieren, dass die Software-Architektur die System- und Software-Anforderungen […] implementiert“ lautet die Forderung der IEC 62304 im Kapitel 5.3.6 zur Verifizierung der Software-Architektur. Ein kurzer Satz, der viele Herstellern fragen lässt: „Und wie mache ich das?“

Diese Nachverfolgung der Software-Anforderungen zur Software-Architektur ist alles andere als trivial. Oft gelingt es noch, die Anforderungen eindeutig zu nummerieren. Ab wie soll man von dort auf ein einziges Architektur-Dokument verlinken können? Ein Dokument in dem die verschiedensten architekturellen Aspekte behandelt werden. Möglicherweise von der Wahl der Programmiersprache über ER-Diagramm für die statische Sicht bis hin zu UML-Verteilungsdiagrammen und Begründungen für bestimmte Architekturpattern.

Diese Verbindung (die Traceability zwischen Requirements und Architektur) wird besonders dann Schwierigkeiten bereiten, wenn das Architekturdokument viel (unstrukturierten) Fließtext enthält. Fließtext halte ich generell für herausfordernd. Denn unsere Sprache ist so vielgestaltig und nuanciert, dass die Eindeutigkeit schnell leidet: Eine Passivkonstruktion, und schon muss man über den Akteur keine Aussage machen. Ein Konjunktiv, und schon bleibt es im Unklaren, ob dieser Aspekt verpflichtend ist oder nicht, oder nur eine Überlegung des Autos wiedergibt. Daher mein Plädoyer:

• Nutzen Sie lieber Modelle statt Text. Hier sind die Ausdrucksmöglichkeiten sehr eingeschränkt und die Aussagen damit eindeutiger. Modelle in Form von Bildern erlauben einen schnellen Überblick und einfachere Diskussion.
• Halten Sie Ihr UML-Diagramm “sauber” von zu vielen Metadaten. Verunstalten Sie es nicht durch Links zu den Software-Anforderungen. Ich empfehle Ihnen aber, im UML-Klassen/Komponentendiagramm die Sicherheitsklassen gemäß IEC 62304 (farblich) zu kennzeichen, ebenso Komponenten anderer Hersteller (SOUPs).
• Strukturieren Sie das Architektur-Dokument in viele Kapitel. Ein Textabschnitt sollte eine halbe Seite nicht überschreiten, bevor er durch eine neue Überschrift unterbrochen wird. So können Sie über die Überschriften relativ genau auf einen Architekturaspekt verweisen (verlinken): „realisiert in Komponente X (siehe Kapitel m)“, „wird berechnet durch Methode Y(siehe Kapitel n)“, „ist gelöst durch Wahl der Technologie Z (siehe Kapitel o)“.
• Fügen Sie ein eigenes Kapitel (ggf. sogar ein eigenes Dokument) ein, das der Traceability gewidmet ist. Listen Sie darin die Anforderungen (erneut) auf und schreiben Sie zu jeder einen ganz kurzen Satz mit einem Verweis auf eines dieser Teilkapitel im Architekturdokument.

Traceability zwischen Software-Anforderungen und Software-Systemtests

Das Tracing zwischen Software-Anforderungen und Software-Systemtests gestaltet sich hingegen oft etwas einfacher, da Sie sowohl die Software-Anforderungen als auch die Software-Systemtests (im Gegensatz zu Architekturaspekten) einfach durchnummerieren können.

Allerdings benötigt man für diese Traceability zwischen beiden eine n:m-Beziehung. Das lässt sich über eine Tabelle ausdrücken, die zeigt, welche Systemtests welche Anforderungen testen, und welche Anforderungen durch welche Systemtests geprüft werden.

Traceability und ISO 14971

Ähnlich der Beziehung zwischen Software- bzw. System-Anforderungen und Software- bzw. Systemtests verhält es sich bei der ISO 14971. Die Norm fordert die Traceability

1. zwischen Risiken und Maßnahmen zur Risikobeherrschung und
2. zwischen Maßnahmen und der Verifizierung der Maßnahmen (genauer mit der Überprüfung, ob diese implementiert und wirksam sind).

Beide Beziehungen pflegen Hersteller üblicherweise in einer “Risiko-Tabelle”, die manchmal auch fälschlich als “FMEA-Tabelle” bezeichnet wird.

Werkzeuge für die Traceability

Dass die Word-gestützte Dokumentation schwierig ist, weiß ich. Besonders weil die Verlinkung über Dokumentengrenzen hinweg nicht funktioniert. Aber das ist ja genau der Grund, aus wir MedPack und RiskPack entwickelt haben. MedPack und RiskPack sind Add-ons zu dem „Application Lifecycle Management“ Werkzeug Polarion. Damit bekommt man das Traceability-Chaos besser in den Griff. Das finden übrigens auch die Auditoren. Denn unser Tool hat sich in einigen Audits bewährt. Nicht nur der Auswertungen wegen, die fehlendes Traces direkt anzeigen.

Sie können auch andere ALM-Werkzeuge nutzen. Diese eigenen sich, wenn Sie sie richtig konfigurieren, um die Traceability bei der IEC 62304 herzustellen. Bei der ISO 14971 tun sich die Werkzeuge schwerer, weil die Risiken keine üblichen “Entities” sind. Auch diese ließen sich ergänzen, aber dann müsste man das ganze Risikomanagement damit abbilden. Und das kann meines Wissens nur RiskPack.

Change Requests sind meist formalisierte und dokumentierte Anträge oder Wünsche an die Änderung eines Produkts bzw. einer Software. Bei Medizinprodukten gilt es, bei Change Requests die regulatorischen Anforderungen zu erfüllen.

Change Requests im Licht der Normen

Change Requests und Risikomanagement (ISO 14971)

Viele Firmen arbeiten mit Ticket- bzw. ALM-Systemen, mit denen sie den kompletten Workflow abbilden, vom ersten “Customer Request” über das Release des Produkts bis zum späteren Change Request. Dabei fällt mir gelegentlich auf, dass es in den Tickets ein „Risikoklassifizierung“ in Form einer Dropdown-Liste gibt, mit Hilfe derer man abschätzen soll, ob ein „Request“ kritisch sei oder nicht. Der weitere Workflow hängt teilweise von dieser Einschätzung ab.

So gut ich es finde, dass man sich sehr früh über Auswirkungen von Änderungen am Produkt Gedanken macht, so sehr möchte ich davor warnen, diese Klassifizierung nur am Anfang und nur auf Basis des Change Requests vorzunehmen.

Ohne Kenntnis des Nutzungskontexts, ohne Kenntnis der inneren Struktur (der System- oder Softwarearchitektur) ist so eine Abschätzung – letztlich bedürfte es einer Gefährdungs- und Risikoanalyse – nicht möglich. Daher darf es nicht einzig dem Produktmanager oder Support-Mitarbeiter überlassen sein, Risiken einzuschätzen. Das ist die Aufgabe eines Teams aus Risikomanager, Produktmanager und System- oder Softwarearchitekt(en). Wenn die Schnittstellen z.B. die GUI geändert wird, müssen Sie ggf. sogar die Kontextexperten und Ärzte involvieren.

Dieser Change Request findet aus Sicht Risikomanagements  in der sog. nachgelagerten Phase statt und muss damit die Forderungen der ISO 14971 (Kapitel 9) erfüllen.

Change Requests und IEC 62304

Auch die IEC 62304 hat genaue  Vorstellungen, mit Bezug zu diesen Change Requests. Zum einen erwartet Sie das Erfassen von Information,

• als Änderungsanforderungen für die Entwickler und
• für die Trendanalyse z.B. mit Hinblick auf den Problemlösungsprozess der IEC 62304

Dann geht es bei den Change Requests um die Freigabe, dass überhaupt etwas geändert werden darf. Die IEC 62304 spricht hier nicht von Change Requests sondern vom Konfigurationsmanagementprozess.

Change Requests und ISO 13485 bzw. FDA

Sowohl die FDA als auch die ISO 13485 stellen Anforderungen an die Corrective and Preventive Actions. Den Fehler nur zu beheben, genügt nicht. Es geht auch um Vorbeugemaßnahmen.

Was sind eigentlich Change Requests?

Die meisten Medizinproduktehersteller unterscheiden bei Change Requests, die von Anwendern kommen, nicht zwischen User Request und User Requirement. Meist entsprechen die User Requests konkreten System-/Software-Anforderungen bzw. System-/Software-Spezifikationen und eben nicht User Requirements.

Hersteller sollten in Ihren Ticket-Systemen beides unterscheiden, so wie auch die FDA und die ISO 13485 Stakeholder-Anforderungen (hierzu zählen User Requirements) und System-Anforderungen unterscheiden.

Werkzeuge für das Verwalten von Change Requests

Zu den Vertretern von Werkzeugen für das Verwalten des Application Lifecycles zählen

• JIRA
• TeamFoundationServer
• Polarion mit dem speziellen Add-ons MedPack und RiskPack für die IEC 62304 und ISO 14971 konforme Dokumentation.

Mit einigen Ticketsysteme wie Bugzilla oder Mantis lässt sich der Software-Lifecycle nicht einfach IEC 62304-konform abbilden.

Das FDA Guidance Dokument Cybersecurity in Medical Devices wendet sich an alle Medizinproduktehersteller, der Produkte Software enthalten oder eigenständige Software sind. Das Guidance-Dokument legt fest,

• wie Hersteller das Risikomanagement um das Thema Cybersecurity ergänzen müssen,
• welche Aspekte sie dabei konkret beachten bzw. umsetzen sollen und
• wie sie diese Maßnahmen zu dokumentieren haben.

Zum Vergrößern klicken

Diese Dokumentation müssen die Hersteller bei einer Zulassung z.B. nach 510(k) einreichen.

Zusammenspiel von FDA Cybersecurity Guidance und Risikomanagement

Der Vorschlag der FDA im Cybersecurity Guidance Dokument, wie die Hersteller vorgehen sollen, entspricht dem üblichen Risikomanagement, bei dem eine FMEA zum Einsatz kommt:

1. Die Hersteller sollen die Schnittstellen der Software wie Netzwerk (WLAN, Kabel) und Laufwerte (USB, CD) identifizieren und jeweils Schwachstellen und Bedrohungsszenarien analysieren. Bei einer FMEA wären das die Inputs.
2. Anschließend sollen die Hersteller die Gefährdungen abschätzen, die sich bei diesen Angegriffen und über diese Schnittstelle ergeben für die Patienten, die Anwender und das Medizinprodukt selbst. Berücksichtigen Sie bei der Risikoanalyse Risiken durch unautorisierten Zugriff, durch Veränderungen, Missbrauch oder „Denial of Use“ oder durch die Verletzung der Vertraulichkeit der Daten. Kurz es geht wie immer bei IT-Security und die CIA-Aspekte
   C: Confidentiality
   I: Integrity
   A: Availability
   Im Gegensatz zur klassischen IT-Security stehen hier aber Risiken für Patienten, Anwender und Dritte im Fokus. Es geht somit um körperliche bzw. gesundheitliche Schäden, weniger um Materielle.
3. Wie im Risikomanagement üblich müssen für diese Gefährdungen die Wahrscheinlichkeiten und damit die Risiken abgeschätzt werden.
4. Im letzten Schritt müssen die Hersteller die Maßnahmen festlegen, die Restrisiken und die Risikoakzeptanz abschätzen.

Damit lassen sich die Forderungen des FDA Cybersecurity Guidance Dokuments im Rahmen des „normalen“ Risikomanagements erfüllen.

Spezifische Forderungen im FDA Cybersecurity Guidance Dokument

Die FDA hat ein konkretes Modell vor Augen, mit dem Hersteller vorgehen sollen:

1. Identify: Wie eben dargestellt sollen die Schnittstellen und damit verbundenen Schwachstellen und Angrifsszenarien identifiziert werden.
2. Protect: Bei den Maßnahmen sieht die FDA v.a. den Zugriffsschutz und die Sicherstellung der Integrität der Software vor.
3. Detect: Weiter wünscht die FDA im Cybersecurity Guidance Dokument, dass mögliche Kompromittierungen automatisch erkannt und dokumentiert werden.
4. Respond: Benutzer müssen auf diese Probleme hingewiesen werden, wobei eine Mindestfunktionalität des Produkts gewährleistet bleiben muss (um Risiken durch einen vollständigen Ausfall des Geräts zu minimieren).
5. Recover: Es sollten Möglichkeiten aufgezeigt werden, wie das Medizinprodukt wieder in einen integren Zustand zurückgeführt werden soll.

Forderungen des FDA Cybersecurity Guides an die Dokumentation

Die Dokumentation geht über die des reinen Risikomanagements hinaus. Die Hersteller müssen laut Cybersecurity Guidance Dokument zusätzlich zum Risikomanagement (Gefährdungen, Risiken, Maßnahmen) dokumentieren:

• Einen Plan, wie Sie die Software aktualisiert halten wollen, um auf neue Sicherheitsbedrohungen reagieren zu können
• Eine Beschreibung, wie der Hersteller die Integrität bereits vor der Auslieferung an den Kunden sicherstellen will
• Anweisungen an die Kunden, wie sie das Produkt bedienen sollen und welche Laufzeitumgebung (z.B. Firewalls, Antivirus-Software) bereitgestellt werden muss

510(k) und FDA Guidance Dokument „Cybersecurity in Medical Devices“

Das Cybersecurity Guidance legt nicht nur fest, welche Dokumentation Hersteller bei einer Zulassung z.B. nach 510(k) (Premarket Notification PMN) einreichen müssen. Das Guidance Dokument sagt auch, dass Änderungen an der Software einzig mit dem Zweck, Cybersecurity Bedrohungen gerecht zu werden, in der Regel keiner neuen Zulassung bedürfen.

D.h. die FDA kommt uns zumindest ein kleines bisschen entgegen.

Weitere Quellen

Die FDA referenziert in dem Dokument weitere Quellen wie die IEC 80001. In diesem Zusammenhang ist auch das FDA Guidance Document „Cybersecurity for Networked Medical Devices Containing Offthe-Shelf (OTS) Software“ zu erwähnen.

Die IEEE 830 ist eine Norm, die beschreibt, wie man Software Anforderungen bzw. Software Spezifikationen beschreiben sollte. Die IEEE 830 schlägt dazu mindestens drei Kapitel vor:

1. Einleitung mit Dokumenten Meta-Informationen (Zweck, Verweise, Aufbau) und mit einer Übersicht über die Software
2. Allgemeine Beschreibung der Software: Hier sollte man die Abgrenzung zu/von anderen Systemen ebenso beschreiben wie die wichtigsten Produktfunktionen und Einschränkungen des Lösungsraums. Auch sieht die IEEE 830 eine Charakterisierung der Nutzer als Teil dieses Kapitels vor.
3. Die spezifischen Anforderungen umfassen laut IEEE 830 funktionale und nicht-funktionale Anforderungen, Anforderungen an die Performanz, Qualitätsanforderungen, externe Schnittstellen und sonstige Anforderungen.

Eine detailliertere Kapitelübersicht der IEEE 830 bietet Wikipedia.

Vorsicht mit der IEEE 830 bei Medizinprodukten

Ich möchte Sie warnen, für medizinische Software blind den Empfehlungen dieser Norm zu folgen. Aus mehreren Gründen:

1. Vermischung von Aspekten: Die Norm packt Elemente der Zweckbestimmung, Stakeholder-Anforderungen und System-Anforderungen in ein Dokument zusammen. Gesetze und Normen (z.B. FDA, ISO 13485) unterscheiden diese Informationen und verlangen sogar, dass Sie diese untereinander tracen. Das wird Ihnen nicht gelingen, wenn Sie alles in einem Dokument zusammenrühren.
2. Fehlende Struktur zum Prüfen: Die IEEE 830 bietet Ihnen keine systematische Struktur, die Ihnen hilft, Ihre Anforderungen vollständig zu dokumentieren und einfach auf Vollständigkeit zu prüfen.
3. Aufteilung in funktionale und nicht-funktionale Anforderungen: Diese Aufteilung hat die IEEE 830 von ISO 9126 übernommen. Diese Aufteilung ist nicht mehr zeitgemäß. Vielmehr empfiehlt sich eine Aufteilung nach Schnittstellen. Mehr dazu in den Videotrainings (s.u.).
4. Mangelnde Normenkonformität: Selbst wenn Sie den Vorschlägen der IEEE 830 folgen, haben Sie keine Konformität mit der IEC 62304 gegeben. Es fehlen Aspekte, die die IEC 62304 in Kapitel 5.2 nennt.
5. Innere Logik: Die Aufteilung ist teilweise irreführend. Worin besteht der Unterschied zwischen „Einschränkungen für Entwickler“ (IEEE 830 Kapitel 2.4) und „Design Constraints (IEEE 830 Kapitel 3.4)? So etwas führt leicht zu Redundanzen.

Ich habe Ihnen eine Serie an kostenlosen Videotrainings vorbereitet, in denen ich Ihnen Schritt für Schritt zeige, wie Sie überraschend einfach und schnell, automatisch normenkonform stabile Softwareanforderungen IEC 62304 konform dokumentieren können. Die Aspekte der IEEE 830 haben Sie damit automatisch berücksichtigt.

Kostenlose Videotrainings ansehen

PS: Im Auditgarant lernen Sie, Ihre komplette “Software-Akte” konform mit der IEC 62304 zu dokumentieren.

Mit diesem Beitrag von Armin Gärtner über die Medical Device Regulation MDR öffnen wir diesen Blog auch für Gastautoren. Wir freuen uns, Ihnen dank dieser Experten hier noch mehr hochwertiges Wissen zur Verfügung stellen zu können.

Die Medical Device Regulation MDR löst die Medizinprodukterichtlinien ab

Am 26.09.2012 hat die EU-Kommission Entwürfe für eine neue Medical Device Regulation und eine neue Verordnung über In-Vitro-Diagnostika vorgestellt, die die bestehenden Medizinprodukte-Richtlinien ersetzen sollen. Der Bearbeitungsprozess läuft derzeit noch auf europäischer Ebene.

Die zu ersetzenden Medizinprodukte-Richtlinien sind

• 1993 – Richtlinie 93/42/EWG über Medizinprodukte
• 1998 – Richtlinie 98/79/EG über in vitro Diagnostika

in Kraft getreten. Die Richtlinie 90/385/EWG wird nicht in der Medical Device Regulation aufgehen.

Die deutsche Übersetzung für Medical Device Regulation wäre Medizinprodukteverordnung. Die europäische Medizinprodukteverordnung (Medical Device Regulation MDR) darf aber nicht mit der nationalen Medizinprodukteverordnung MPV verwechselt werden. Um Verwechslungen zu vermeiden, nutzen wir den englischen Begriff Medical Device Regulation.

Unterschied zwischen europäischen Richtlinien und Verordnungen

Europäische Richtlinien

Der Begriff Richtlinie läßt analog dem Begriff „Richtgeschwindigkeit“ auf eine Freiwilligkeit der Anwendung schließen. Aber die EU-Harmonisierungsrichtlinien sind klare Direktiven (Directives), die sich an die sogenannten Wirtschaftsakteure (Hersteller und Inverkehrbringer) richten. Hersteller und/oder Inverkehrbringer müssen generell die Richtlinienanforderungen erfüllen.

Eine EU-Richtlinie wird unter Beteiligung der EU-Mitgliedsländer und der EWR Staaten) erarbeitet und muss gemäß EWG-Vertrag, Art.100a innerhalb einer vorgegebenen Frist (meist 6-24 Monate) über die nationalen Parlamente in nationales Recht umgesetzt werden. Abstriche oder Veränderungen sind nicht gestattet. Aber nationale, darüber hinausgehende Anforderungen sind möglich (z. B.: deutsches Medizinproduktegesetz (MPG) § 31 Medizinprodukteberater).

Europäische Verordnungen

Eine EU-Verordnung wie die Medical Device Regulation MDR wird hingegen von der EU-Kommission in Brüssel ohne direkte Zustimmung der Länderparlamente erlassen und ist innerhalb einer vorgegebenen Frist als europäisches, übernationales Recht anzuwenden. Nationale, darüber hinausgehende Anforderungen sind aber auch hier möglich. Wahrscheinlich wird es – nach heutiger Einschätzung – ein ergänzendes, deutsches Medizinproduktegesetz geben, das als rechtliche Basis für die nationalen Medizinprodukte-Verordnungen, vor allem für die Medizinprodukte-Betreiberverordnung benötigt wird.

Wenn die bisherigen Medizinprodukte-Richtlinien durch die Medical Device Regulation abgelöst wird, die die zwei genannten Richtlinien zusammenfasst, dann tritt die Medical Device Regulation vom Tag des Erscheinens an in Kraft und ist direkt in allen EU-Mitgliedsstaaten anzuwenden.

Warum Ablösung der bisherigen Medizinprodukte-Richtlinien?

Einer der Gründe, die bisherigen Richtlinien abzulösen, ergab sich durch den sogenannten PIP-Skandal. Ein Hersteller verwendete in krimineller Absicht für Brustimplantage Industrie-Silikon anstelle hochreinen medizinischen Silikons. Nach Bekanntwerden dieser Machenschaften ergaben sich Überlegungen, wie man zukünftig derartige kriminelle Prozesse durch eine Verschärfung der Richtlinien verhindern könne.

Änderungen durch die neue Medical Device Regulation

Neben der Zusammenfassung der bisherigen zwei eigenständigen Medizinprodukte-Richtlinien sind derzeit u. a. folgende, wesentliche Änderungen bzw. Neuerungen in dem Entwurf der Medical Device Regulation zu finden:

• Die Anforderungen an den Inhalt der Technischen Dokumentation werden in einem neuen Anhang 2 der Medical Device Regulation zukünftig deutlich detaillierter geregelt.
• Jedes Produkt muss zukünftig eine eindeutige Produktidentifizierungsnummer („unique device ID”, UID) erhalten.
• Es ergeben sich neue Anforderungen an die Etikettierung von Medizinprodukten.
• Ein Hersteller muss eine qualifizierte Person im Unternehmen benennen, die über qualifiziertes Fachwissen auf dem Gebiet der Medizinprodukte verfügen muss.
• Die Datenbank EUDAMED wird erheblich ausgeweitet und öffentlich zugänglich gemacht.
• Es wird eine EU-weite Vereinheitlichung der Tätigkeit und der Prüfbescheinigungen der Benannten Stelle geben.
• Klinische Bewertungen und klinische Prüfungen werden detaillierter geregelt und vorgeschrieben.
• u.a.

Die sich derzeit abzeichnenden Konsequenzen bestehen in einem deutlich erhöhten Dokumentationsaufwand für Hersteller, wenn sie die Anforderungen der zukünftigen Medical Device Regulation MDR konform umsetzen wollen.

Marktüberwachungsbehörden können gemäß Artikel 73 Absatz 1 (d) und (f) der Medical Device Regulation die amtliche Nichtkonformität von Produkten feststellen, wenn keine EU-Konformitätserklärung erstellt wurde, diese unvollständig ist oder die Technische Dokumentation nicht verfügbar oder unvollständig ist. Sorgt dann der Hersteller nicht in angemessener Frist für die Wiederherstellung der Konformität, können Behörden die Bereitstellung (Inverkehrbringen) eines Produktes auf dem Markt untersagen.

Ansonsten beinhaltet die zukünftige Medical Device Regulation MDR keine weiteren Aussagen und Anforderungen an den Betreiber von Medizinprodukten, sodass das sogenannte Betreiberrecht in Form der heutigen Medizinprodukte-Betreiberverordnung weiterhin über nationale Gesetze bzw. Verordnungen vorgegeben werden muss.

Was sind Trends in der Medizintechnik, auf die sich Medizintechniker einstellen sollten, fragt mich ein Interessent des Masterstudiengangs „IT im Gesundheitswesen“. Ich halte für wichtig, dass Mitarbeiter in Krankenhäusern und bei Medizintechnikherstellern diese Trends in der Medizintechnik kennen, um die Karriere daran zu orientieren.  Daher habe ich den Beitrag mit neuen Zahlen des BVmed aktualisiert.

Trends in der Medizintechnik, die Mitarbeiter kennen sollten

In der Medizintechnik beobachte ich folgende Trends:

• Bei Krankenhäusern werden immer mehr Managementfähigkeiten erwartet, weil die originären Aufgaben der Wartung und Instandhaltung von Herstellern übernommen werden.
• Weiter müssen die Medizintechniker in Krankenhäusern (und bei Herstellern) ziemlich viel über IT und Vernetzung von MT und IT wissen. Die standortübergreifende Versorgung von Patienten (Stichwort Telemedizin) und mobile Anwendungen entwickeln sich zur Normalität. Das schließt die Überwachung und Behandlung von Patienten zuhause (z.B. Telemonitoring) mit ein.
• Ebenfalls sehe ich als Trend die immer stärkere Regulierung (siehe z.B. IEC 80001). Letzteres gilt ebenfalls gleichermaßen für Hersteller und Betreiber und drohen, die Kosten zu steigern.
• Ich beobachte eine zunehmende die Disziplinen übergreifende Spezialisierung, beispielweise im Bereich der Sensorik und Molekulardiagnostik.
• Schließlich erwarte ich eine Konvergenz von Medizintechnik und dem Fitness- bzw. Wellness-Bereich.

Kennen Sie weitere Trends in der Medizintechnik? Ich bin an Ihren Einschätzungen interessiert.

Unternehmen in der Medizintechnik

Laut BVmed arbeiten 190.000 Menschen in über 12.600 Medizintechnik Unternehmen. Dabei zählen die 94% Unternehmen zu dem KMUs mit maximal 250 Mitarbeitern.

Die meisten Medizintechnik Unternehmen sind KMUs (Quelle: BVmed)

Wie sich Mitarbeiter auf Trends in der Medizintechnik vorbereiten sollten

Die gute Nachricht vorweg: Die Medizintechnik, die längst die medizinische IT mit umfasst, ist einer der lukrativsten und stabilsten Wachstumsmärkte. So sieht es auch der Philips-Chef. Er prognostiziert einen Megatrend, weshalb sich Philips aus schrumpfenden Märkten zurückzieht und noch stärker auf den Sektor Healthcare setzt. Bei 6,4% Wachstum im letzten Jahr kann man das gut verstehen.

Dieser Markt wächst nicht nur, er wird gleichzeitig auch komplexer. Das Verschmelzen von IT und Medizintechnik, die Notwendigkeit, Patienten sektoren- und ortsübergreifend zu versorgen, komplexe klinische Workflows, die engen Budgets der Krankenhäuser; all das verlangt nach wirklichen Experten. Die nächsten sind auf dem Weg!

Ein Wachstumsmarkt kommt noch keiner Beschäftigungsgarantie gleich. Die Mitarbeiter in dieser Industrie sollten

• in der Lage und bereit sein, kontinuierlich zu lernen, um mit den Trends in der Medizintechnik Schritt halten zu können,
• über eine breite Ausbildung verfügen, um Zusammenhänge zu verstehen und den Anforderungen kleiner Firmen zu genügen, die sich nicht für jeden Bereich einen Spezialisten leisten können und
• über Managementkompetenzen und regulatorisches Wissen verfügen.

Die Master-Studiengänge am Institut bereiten sie genau auf diese Trends in der Medizintechnik vor und damit auf eine noch erfüllendere Karriere. Hier noch ein paar weitere Überlegungen zu einem Studium Medizintechnik.

Einer meiner geschätzten Kunden hat mich zum Thema Werkzeug Validierung gefragt, ob man Testwerkzeuge (z.B. JUnit, Winrunner, qfTest) und ALM-Tools (z.B. MedPack, JIRA, microTool, Visual Studio Team Foundation) validieren bzw. verifizieren muss. Und falls die Antwort ja wäre, müsste man dann die zu dieser Validierung bzw. Verifizierung eingesetzten Werkzeuge auch wieder prüfen? Da würde sich ja ein Teufelskreis auftun.

Eine wichtige Frage! Ich habe mir selbst schon Minor-Non-Conformities wegen mangelnder Tool-Validierung “eingefangen”. Lesen Sie hier

• welche regulatorischen Anforderungen an die Werkzeug Validierung bestehen,
• welche Werkzeuge validiert werden müssen und
• wie Sie Ihre Werkzeuge schnell und gesetzeskonform validieren können.

Die Validierung von (Entwicklungs-)Werkzeugen ist gesetzlich vorgeschrieben

Regulatorische Anforderungen an die Werkzeug Validierung

Die Anforderungen an die Werkzeug Validierung finden Sie v.a. in den Regularien mit Bezug zum Qualitätsmanagement.

Anforderung der ISO 13485 an die “Tool Validierung”

Im Kapitel 7.6 (Lenkung und Erfassung von Messmitteln) schreibt die ISO 13485: “Bei Verwendung von Computersoftware zur Erfassung und Messung festgelegter Anforderungen muss die Eignung dieser Software für die beabsichtigte Anwendung bestätigt werden. Dies muss vor dem Erstgebrauch vorgenommen und wenn notwendig auch später bestätigt werden.”

D.h. Entwicklungswerkzeuge sind dann zu validieren, wenn Sie ein Messmittel darstellen.

Weiter lesen wir in Kapitel 8.2.3 “Erfassung und Messung von Prozessen”: “Die Organisation muss geeignete Methoden zur Erfassung und, falls zutreffend, Messung der Prozesse des Qualitätsmanagementsystems anwenden. Diese Methoden müssen darlegen, dass die Prozesse in der Lage sind, die geplanten Ergebnisse zu erreichen.”

D.h. Werkzeuge, die zur Messung von Prozessen des QM-System (z.B. des Entwicklungsprozesses) genutzt werden, müssen Sie ebenfalls der Werkzeug Validierung unterziehen.

Im Kapitel 7.5.2.1 zu den “allgemeine Anforderungen an die Validierung der Prozesse zur Produktion und zur Dienstleistungserbringung” finden Sie noch folgende Forderung: “Die Organisation muss dokumentierte Verfahren für die Validierung der Anwendung der Computersoftware (und von Veränderungen an solcher Software und/oder ihrer Anwendung) festlegen, die bei Tätigkeiten in der Produktion und Dienstleistungserbringung eingesetzt wird und die die Fähigkeit des Produkts, festgelegte Anforderungen zu erfüllen, beeinflussen kann. Solche Softwareanwendungen müssen vor dem ersten Einsatz validiert werden.”

Beispiele für zu validierende (Entwicklungs-)Werkzeuge

Wohlgemerkt, wir sprechen hier nicht von der Software, die Teil des Medizinprodukts wird wie Datenbanken, Betriebssysteme, Bibliotheken und sonstige SOUPs, sondern von Werkzeugen.

Werkzeuge die der Messung des Produkts dienen

• Unit-Test-Werkzeug
• Werkzeug für die statische Code-Analyse
• Automatische GUI-Tests
• Software im Prüfstand

Eine IDE muss nicht per se validiert werden, es sei denn sie enthält Messfunktionen beispielsweise die eben genannten. Andere Werkzeuge wie Versionsverwaltungssysteme oder UML-Modellierungswerkzeug müssen Sie nicht validieren.

Werkzeuge, die der Messung von Prozessen dienen

Viele Hersteller nutzen ALM- und Ticketing-System auch zur Messung der Prozessgüte um z.B. folgende Größen zu bestimmen:

• Anzahl der Fehler pro Zeiteinheit
• Verhältnis und Trends kritischer und unkritischer Fehler
• Zeiten zum Beheben von Fehlern
• usw.

Auch diese Werkzeuge — genau gesagt die Teile dieser Werkzeuge der den Messungen dienen — wären zu validieren.

Tipps für die Validierung von Werkzeugen

Der Begriff Verifizierung in diesem Kontext erscheint bei Software etwas problematisch. Eigentlich ist es eine Validierung, nämlich eine Prüfung, ob das Werkzeug den Nutzungszweck tatsächlich erfüllt. Bei einem Testwerkzeug müsste beispielsweise geprüft werden, ob Fehler tatsächlich gefunden werden und ob das Werkzeug bei fehlerfreier Software auch keine Fehler meldet.

1. Es empfiehlt sich, den Aufwand für die Verifizierung/Validierung der Messwerkzeuge (zumindest solange diese bereits im Markt bewährt sind) zu beschränken. Prüfen Sie v.a. die absolute und für Sie relevante Kernfunktionalität sowie die Bereiche der Software, die Sie durch Konfiguration für sich spezifisch gestaltet haben (Customizing). Sie wollen die Qualitätssicherung ja nicht zum Selbstzweck machen, sondern für sich (und den Auditor) weitgehend sicherstellen, dass das Werkzeug seinen Zweck erfüllt. Die Wahrscheinlichkeit einen Fehler in einem 100.00-fach eingesetzten Werkzeug wie NUnit, CPPUnit oder JUnit zu finden, ist eher gering. Mein Tipp: Fokussieren Sie sich auf den für Sie spezifischen Teil des Werkzeugs („Customizing“) und die eigene Software selbst. Die Werkzeug Validierung kann in 30 Minuten abgeschlossen sein.
   Die Wahrscheinlichkeit in der eigenen Software einen Fehler zu haben, ist um Größenordnungen höher als bei kommerziellen oder Open-Source Werkzeugen.
2. Achten Sie beim Verifizieren/Validieren darauf, ISO 13485-konform zu dokumentieren. Die Dokumentation Ihrer Validierung/ Verifizierung sollte enthalten:
   • Die Version des Werkzeuges, das geprüft wird
   • Die Testspezifikation, die Testdaten, die Testergebnisse und ggf. ein Verweis auf das dazu verwendete Werkzeug
   • Den Autor, das Datum und eine Unterschrift/Freigabe
   • Tipp: packen Sie alles in ein Versionsverwaltungssystem oder auf eine CD. Wiederholen Sie diese Prüfung, wenn Sie Ihr Werkzeug updaten.
3. Man muss natürlich nicht über den Source-Code des Werkzeugs verfügen. Die Verifizierung/Validierung ist ein Blackbox-Testing. Und die Werkzeuge, die Sie zur Prüfung der Werkzeuge einsetzen, muss man nicht selbst validieren/verifizieren (, es sein denn, man setzt diese Werkzeuge auch zum Prüfen des eigentlichen Produkts/Prozesses ein). Andernfalls käme man ja in einen unendlichen Zyklus.

Bei den Audits, die ich selbst über mich ergehen ließ oder bei denen ich meine Kunden unterstützte, war es meist entscheidend, dass das Werkzeug überhaupt und sei es noch so minimal geprüft und dies auch dokumentiert wurde. Der Umfang dieser Prüfungen wurde nie bemängelt. Falls dies doch erfolgen sollte, empfehle ich, den Auditor auf die Wahrscheinlichkeiten aufmerksam zu machen, einen Fehler in einem Werkzeug und im eigenen Code zu finden. Er soll bitte seinen Auditschwerpunkt darauf zu legen, wo die Fehler am wahrscheinlichsten sind. Und das bleibt nun mal der eigene Code.

Unterstützung bei der Validierung Ihrer Software-Werkzeuge

Sie sind sich nicht ganz sicher, ob die Validierungen Ihrer Software vollständig sind und im Audit bestehen würden? Sie fragen sich, ob Ihr QM-Handbuch die Software-Validierung adäquat behandelt?

Wir helfen Ihnen gerne mit einer schnellen Einschätzung. Das kostet Sie nicht viel. Und wenn in Ihrem QM-Handbuch noch Lücken sind, dann schließen wir diese ebenso schnell und für Sie bequem. Wir haben als Auditoren und Software-Entwickler viel Erfahrungen darin, wie man Normenkonformität erreicht, dabei keinen QM-Overhead erzeugt und es sogar schafft, schneller und preisgünstiger medizinische Software zu entwickeln.

Nehmen Sie Kontakt mit uns auf!

Kontakt aufnehmen

Weitere Gedanken zur Werkzeug Validierung

Mein Partner Bernhard Fischer und ich diskutieren oft gemeinsam die Fragen, die in unserer kostenlosen Sprechstunde landen. Eines der Themen, bei denen ich zuerst anderer Meinung war als Bernhard, ist das Validieren von Testwerkzeugen.

Bernhard hat mir hierzu folgenden, wie ich finde exzellenten Beitrag geschrieben:

Lieber Christian,

ich habe eben Deinen Blog gelesen. Mich nervt der Zwang zur Validierung von Testwerkzeugen nicht. Es beschwert sich ja auch keiner, dass Messwerkzeuge kalibriert werden müssen. Und ich halte beides für vergleichbar. Gut, ich gebe zu, es gibt sicherlich Trivialfälle, wie eben Dein JUnit.

Aber häufig ist es eben nicht dieser Fall. Mittlerweile werden hochkomplexe Werkzeuge für Test eingesetzt. Einer meiner Kunden führt Komponententests aus, bei dem Test auf der Basis von LabView geschrieben werden, ein anderer verwendet Open Source-Tools zur Unit-Tests von VHDL-Code, ein weiter verwendet selbst geschriebene Simulatoren in Kombination mit einen kommerziellen Testwerkzeug. Sollen alle unterstellen, dass die Werkzeuge schon tun, was wir von ihnen erwarten?

Besser nicht. Vor zwei Wochen ist es immerhin schon im dritten Anlauf gelungen, ein Testwerkzeug zu validieren. Die beiden vorherigen Male schlugen fehl, weil der Anwender falsche Vorstellungen darüber hatte, wie sich das Werkzeug verhielt bzw. verhalten sollte.

Als Fazit: Ja, manchmal ist es lästig. Trotzdem sollten wir keinesfalls auf die Validierung verzichten.

Liebe Grüße

Bernhard

23andMe: endlich FDA-Clearance? (Februar 2015)

Stück für Stück kämpft sich 23andMe zurück. Zwar hat die Firma nun eine FDA Clearance, aber nur für einen einzigen Test, wie engadget berichtet. Dies zeigt, wie schwierig sich 23andMe damit tut, die regulatorischen Anforderungen v.a. der FDA zu erfüllen. Wahrscheinlich betreffen die Herausforderungen v.a. den Nachweis der klinischen Wirksamkeit zumal 23andMe nicht nur das Medizinprodukt FDA-konform in Verkehr bringen muss, sondern teilweise die zugrundeliegende Forschung betreibt.

Mich würde zudem interessieren, wie 23andMe die Software und Algorithmen dokumentiert — die Software Requirements Specification, die Software-Architektur und zugehörigen Verifizierungen.

Danke an JN

23andMe: jetzt mit CE-Zeichen (Dezember 2014)

Offensichtlich hat sich 23andMe davon überzeugen lassen, dass ihre Produkte doch Medizinprodukte sind. Nach dem FDA-Warning Letter hat die Firma nun sogar ein CE-Zeichen erhalten, wie “SmartBrief” berichtet:

Mich würde ja die technische Dokumentation sehr interessieren, v.a. der Teil klinische Bewertung und Risikomanagement.

Wenn es wirklich darauf ankommt (konkret, wenn ich eine Krebserkrankung zu bekämpfen hätte), würde ich mich aber eher den Diensten der Firma Molecular Health anvertrauen. Die WELT berichtet über diese vorbildliche Firma. Ich weiß, über was ich spreche.

Danke an Peter Müllner

23andMe in Trouble (Dezember 2013)

Über die Firma 23andMe habe ich mehrfach berichtet; beispielsweise darüber, dass ich deren Dienstleistungen nutzte und welche Ergebnisse ich bekam. Aber auch darüber, dass 23andMe offensichtlich mehrfach fehlerhafte Berichte erstellte.

Nun hat die FDA einen Warning-Letter an die Firma geschickt, der es in sich hat. Der Firma wird vorgeworfen, dass sie ein Medizinprodukt in Verkehr bringe und aktiv bewerbe, das offensichtlich keine FDA Clearance hat. Diese Abmahnung dürfte für die Firma nicht überraschend kommen, denn die Diskussionen mit der FDA scheinen bereits Jahre anzudauern, ohne dass die Firma es geschafft hätte, den gesetzlichen Anforderungen nachzukommen.

Noch ist die Webseite online, noch kann man die Kits kaufen. Aber die 15 Tagefrist der FDA dürfte kaum ausreichen, das Problem ausreichend zu adressieren.

So sehr ich es bedauern würde, dass Gentests nicht mehr so einfach und preisgünstig verfügbar sind, so nachvollziehbar finde ich die Argumentation der FDA. In diesem Fall habe ich sogar den Eindruck, 23andMe habe versucht, die Sache auszusitzen, vielleicht sogar sich mit der FDA anzulegen. So etwas geht selten gut. Auch wenn die Besitzerin Frau (Ex-)Google ist.

Danke an MW, MK, DrCJ, US

23andMe gibt nach!

Der erste Blog-Beitrag von 23andMe nach dem Warning-Letter der FDA klang fast noch etwas trotzig, und die Firma verkaufte weiterhin das Test-Kit. Doch damit ist jetzt Schluss:

Die Firma gibt nach und stellt ihr Angebot ein. Mit eine Polizeibehörde zu argumentieren, ist sicher auch nicht besonders klug.

Übrigens: Im Jahr 2009 hatte ich 23andMe meine (kostenlose!) Hilfe bei der FDA-konformen Dokumentation ihrer Entwicklung angeboten (Ich hatte damals mein US-Forschungssemester vor mir). Man bedanke sich höflich und meinte, kein Medizinprodukt zu sein…

Selbsttest: Ich habe meine Probe eingeschickt

Ich habe es getan. Mich völlig entblößt. Völlig nackt, bis auf letzte Gen. Im Selbstexperiment “personalisierte Medizin” will ich wissen, was die Molekulardiagnostik glaubt, über mich zu wissen.

Meine Speichelprobe ist eingeschickt, 23andMe hat meine Daten. Jetzt weiß Google alles über mich (die Frau von “Herrn Google” ist die Eigentümerin von 23andMe).

Und bald weiß ich Dinge, die ich vielleicht nie wissen wollte. Ich halte Sie auf dem Laufenden.

Mein erster DNA Test: Ein bisschen Tuareg

23andMe schreibt mir eine E-Mail. Meine Gendaten seien weiter ausgewertet worden – es gäbe neue Informationen zu meinen Vorfahren. Da bin ich mal gespannt. Also gleich einloggen und sehen, von wem ich abstamme.

Aha, zu 99,3% bin ich Europäer. Gut, diese Diagnose hätten Sie mir wahrscheinlich etwas preisgünstiger stellen können.

Aber zu 0,1% habe ich auch nordafrikanisches Blut in mir. Habe ich meine Freiheitsliebe den Tuaregs zu verdanken?

genetische Vorfahren

Mehr Details der Analyse: Stehe ich kurz vorm Herzinfarkt?

Die Ergebnisse meiner Genanalyse sind da. Mehrfach muss ich bestätigen, dass ich sie auch wirklich sehen will. Ich stimme zu – und erschrecke:

Der Bericht beginnt mit einer Liste an Krankheiten, an denen ich überdurchschnittlich wahrscheinlich erkranken werde. Besonders exponiert scheine ich für koronare Herzerkrankungen zu sein. Mit über 60%-iger Wahrscheinlichkeit werde ich daran erkranken. Da fühlt man sich doch schon mal gleich ganz schlecht.

Natürlich muss man relativierend beachten, dass über 46% der Durchschnittsbevölkerung ebenfalls an dieser Krankheit leiden werden, ich also “nur” eine 1,3-fache Wahrscheinlichkeit habe. Dennoch, nachdenklich stimmt das schon.

Interessanterweise widersprechen die Ergebnisse diametral den Aussagen meines Arztes. Das ist aber auch nicht verwunderlich, denn er berücksichtigt Parameter, die einen fast noch stärkeren Einfluss auf das Entstehen dieser Krankheit haben als die Gene: Beispielsweise Sport, Blutdruck, Alkoholgenuss, und Cholesterin. Es würde mich wirklich interessieren, wie diese Parameter die Rechnung von 23andMe beeinflussen. Denn so hat man nur die halbe Wahrheit, und die hilft mir nur bedingt weiter. Ich lebe bereits sehr gesund, was die tatsächliche Wahrscheinlichkeit einer koronaren Herzerkrankung wahrscheinlich deutlich unter das der Durchschnittpopulation drückt.

Einmal mehr wird klar, dass medizinische Daten nur dann zu handlungsrelevantem Wissen verarbeitet werden können, wenn sie vollständig und korrekt sind. Doch daran scheitern wir regelmäßig. Mangelnde Interoperabilität der Systeme, mangelnder Wille und mangelndes Verständnis der Beteiligten führen zu Datenfriedhöfen und verpassten Chancen für die Forschnung und Patienten.

Übrigens: Google weiß alles

Der letzte Institutstag stand ganz im Zeichen der personalisierten Medizin und damit auch der Molekularmedizin. Dabei kam auch zur Sprache, dass Google indirekt an dem Dienstleister 23andMe beteiligt ist.

Was Google mit dem folgenden Bild ausdrücken will, ist mir nicht ganz klar. „Wir suchen auch nach Gendaten?“ „Wir wissen alles über Euch?“

Weil mich weiter viele Fragen zu den Sicherheitsklassen der IEC 62304 erreichen, habe ich alle bisherigen Beiträge zu diesem Thema konsolidiert. Daher ist dieser Artikel zu den Sicherheitsklassen etwas umfangreicher geworden.

Die IEC 62304 hat das Konzept der Sicherheitsklassifizierung eingeführt, damit Medizinproduktehersteller den Aufwand für die Software-Dokumentation an den Grad möglicher Schäden anpassen können, die durch einen Softwarefehler verursacht würden. Die IEC 62304 unterscheidet drei Sicherheitsklassen:

• Klasse A: Keine Verletzung oder Schädigung der Gesundheit ist möglich
• Klasse B: Keine SCHWERE VERLETZUNG ist möglich
• Klasse C: Tod oder SCHWERE VERLETZUNG ist möglich

Eine schwere Verletzung definiert die Norm dabei als “Verletzung oder Krankheit, die direkt oder indirekt lebensbedrohend ist, zu einer andauernden Beeinträchtigung einer Körperfunktion oder zu einer andauernden Schädigung des (menschlichen) Körpers führt oder ein medizinisches oder chirurgisches Eingreifen erfordert, um eine andauernde Beeinträchtigung einer Körperfunktion oder eine andauernde Schädigung des (menschlichen) Körpers zu verhindern”.

Obwohl diese Definition klar ist, zählt das Thema Sicherheitsklassen mit zu den meisten Fragen in meiner kostenlosen Auditsprechstunde.

Sinn der Sicherheitsklassen

Sicherheitsklassen haben das Ziel den Dokumentationsaufwand zu steuern.

Für Software der Sicherheitsklasse A müssen Hersteller nur die Software-Anforderungen (5.2) und die Software-Freigabe (5.8) dokumentieren, bei Klasse B kommt die Software-Architektur (5.3) und die Software-Verifikation (5.5 bis 5.7) hinzu, und bei Sicherheitsklasse C auch das detaillierte Design (5.4).

Allerdings halte ich viele Diskussionen wegen Klasse B oder C für wenig zielführend. Was sind auch die Unterschiede? Dass man kein detailliertes Design und keine Unit-Tests macht? Das sind Dinge, die meine Studenten in dritten Semester lernen. Und sobald man Richtung FDA schaut, wird diese Diskussion sogar völlig absurd. Denn dort müssen unabhängig vom Level of Concern alle Dokumente erstellt, nur nicht eingereicht werden.

Reduktion der Sicherheitsklassen

Definition

Die IEC 62304 legt fest: “Wenn das RISIKO des Todes oder einer SCHWEREN VERLETZUNG, das von einem Software-Fehler herrührt, anschließend durch eine Hardware-RISIKOKONTROLL-Maßnahme auf ein vertretbares Maß verringert wird (wie in ISO 14971 definiert), und zwar dadurch, dass die Folgen des Fehlers verringert werden oder dass die Wahrscheinlichkeit des Todes oder einer SCHWEREN VERLETZUNG, die von diesem Fehler herrührt, verringert wird, so kann die Software-Sicherheitsklasse von C auf B herabgesetzt werden.”

Mit Hardware ist entweder Mechanik oder zumindest ein zweites System mit einem unabhängigen Prozessor und Speicherbereich gemeint.

Auch innerhalb eines Software-Systems können einzelne Komponenten eine reduzierte d.h. kleinere Sicherheitsklasse haben, als das übergeordnete Software-System selbst. Das müssen die Hersteller aber begründen, was in der Regel nur mit Hilfe einer dokumentierten und geeigneten Software-Architektur möglich ist.

Beispiel

Rechtfertigt ein Notaus-Schalter, die Sicherheitsklasse einer Software um eine Klasse zu reduzieren, lautet die spannende Frage. Die Frage ist auch deshalb spannend, weil sie das ganze Dilemma der IEC 62304 zeigt: Auf der einen Seite ignoriert die Norm bei den Sicherheitsklassen die Wahrscheinlichkeit, auf der anderen Seite spricht sie bei den Hardwaremaßnahmen von Risiken — die definitionsgemäß Wahrscheinlichkeiten beinhalten:

Das bedeutet, dass sich die Frage nur aus dem Risikomanagement beantworten lässt: Wenn der Notaus-Schalter das Risiko auf ein vertretbares Maß verringert wird — und nur dann(!) — ist die Reduzierung der Sicherheitsklasse vertretbar. Da in den meisten Fällen wie auch diesem die Reduktion des Risikos nur durch eine Reduktion der Wahrscheinlichkeit erfolgt, müssten Sie begründen, um wie viele Größenordnung die Wahrscheinlichkeit abnimmt und dann in Ihrer Risikoakzeptanzmatrix nachsehen, ob Sie dann in einem akzeptablen Bereich landen. Die Definition Ihrer Risikoakzeptanzmatrix, genauer gesagt der Wahrscheinlichkeitsachse, muss daher auch quantitativ erfolgen. Sonst fehlt Ihnen eine Begründung, weshalb Sie die Sicherheitsklasse Ihrer Software von C auf B bzw. von B auf A reduziert haben.

Eigentlich müssen man von einer 100% Fehlerwahrscheinlichkeit der Software ausgehen. D.h. wenn man durch die Maßnahme die Wahrscheinlichkeit um zwei Größenordnungen senken könnte (schon das wird nur schwer argumentierbar sein), hätten man eine 1%-ige Wahrscheinlichkeit, dass das System versagt. Die Wahrscheinlichkeit eines Schadens wird noch niedriger sein. Doch ist die dann erreichte Schadenswahrscheinlichkeit nach der Maßnahme akzeptabel?

Natürlich ist die Annahme der 100% absurd, weshalb ich — in Vorgriff auf die nächste Version der 62304 — bereits heute mit Fehlerwahrscheinlichkeiten kleiner 100% argumentiere.

Zusammenspiel der Sicherheitsklassen

Sicherheitsklassen und Klassifizierung nach MDD

“Gibt es einen Zusammenhang zwischen der Sicherheitsklasse nach IEC 62304 und der Klassifizierung nach MDD?” lautet eine häufige Frage.

Es gibt keine ganz strenge Korrelation zwischen der Klassifizierung nach MDD und der Sicherheitsklasse nach IEC 62304. Kann es auch nicht geben. Ein Beispiel:

Wenn Sie ein hochkritisches Gerät haben, sagen wir Klasse IIb, bei dem die Software aber mit dieser Kritikalität nichts zu tun hat, kann diese Software durchaus Klasse A sein. Umgekehrt kann man aber sagen, dass eine Software der Klasse C eher nicht als Klasse I einzustufen ist. Denn Klasse C bedeutet ja, dass es Tod oder schwere Verletzungen explizit geben kann.

Als Faustformel kann man davon ausgehen, dass aktive Therapiegeräte als Klasse IIa eingestuft sind, wenn nichts Schlimmes passieren kann, andernfalls als Klasse IIb. Das ist natürlich nur eine Faustformel, im Einzelfall sind die Klassifizierungsregeln durch zu deklinieren und im Zweifel (was häufig vorkommt) mit der benannte Stelle zu diskutieren.

Die Kurzantwort auf die Frage lautet somit: Aus einer hohen Klassifizierung z.B. IIb kann nicht auf eine hohe Software-Sicherheitsklasse geschlossen werden. Umgekehrt geht das eher, aber nicht mit mathematischer Beweiskraft.

Sicherheitsklassen und Funktionen

Meine Kunden sind erfinderisch: Offensichtlich begeistert von der IEC 62304 kam einer auf die Idee, die Funktionen (UI-Elemente) eines Medizingeräts direkt mit Sicherheitsklassen in Verbindung zu setzen. Damit könne er direkt alle sicherheitskritischen Software-Teile identifizieren, entsprechend verifizieren und das alles tracen. Eine gute Idee?

Leider nein: Bei Funktionen, d.h. Elementen einer Benutzerschnittstelle, unterscheidet man Elemente zu Eingabe, zur Auswahl und zur Anzeige. Das sind beispielsweise Schalter, Knöpfe, Drop-Down-Menüs, Grafiken, Texte oder Eingabefelder.

Es mag noch möglich sein, ohne Kenntnis der Architektur ein Risiko zuzuordnen. Beispielsweise lässt sich auch ohne Kenntnis des Innenlebens eines Geräts abschätzen, wie hoch und wie wahrscheinlich ein Schaden sein wird, wenn Daten für einen falschen Patienten angezeigt oder der Regler einer Infusionspumpe den Fluss einer Infusionslösung falsch entgegen nimmt.

Was man ohne Kenntnis der Architektur aber nicht abschätzen kann, ist der Beitrag, den die Software dazu liefert. Und mit Architektur meine ich Soft- und Hardwarearchitektur. Möglicherweise ist die Software gar nicht beteiligt oder ein Fehler in ihr würde durch eine Hardwarekontrollmaßnahme erkannt und beherrscht werden. Dann hätten wir ein hohes Risiko, aber Software der Klasse A.

In anderen Worten: Die Funktionen, also alle Arten von Elementen einer Benutzerschnittstelle, gleich ob diese in Hard- oder Software realisiert sind, lassen u.U. eine Korrelation mit dem Risiko, nicht aber mit einer Softwaresicherheitsklasse zu.

Sicherheitsklassen für bestimmte Produkte

1. Klassifizierung von Überwachungssoftware

Die IEC 62304 erlaubt, dass diese Klassen durch Hardware-Risikokontrollmaßnahmen reduziert werden. Diese Kontrollmaßnahmen dürfen selbst wieder Software enthalten. Doch welche Klasse hat dann diese “überwachende” Software?

Die Norm schreibt dazu:

Der HERSTELLER muss jedem SOFTWARE-SYSTEM, das zur Implementierung einer RISIKOKONTROLL-Maßnahme beiträgt, eine Software-Sicherheitsklasse zuordnen. Sie basiert auf den möglichen Auswirkungen derjenigen GEFÄHRDUNG, die durch die RISIKOKONTROLL-Maßnahme kontrolliert wird.

Das heißt wiederum, dass die Software, mit der die Risikokontrollmaßnahme realisiert wird, die gleich Sicherheitsklasse besitzt, wie die Software, die damit überwacht/kontrolliert wird.

2. PACS

Eine PACS-Software lässt sich nur in eine Sicherheitsklasse gemäß IEC 62304 einordnen, wenn man die Zweckbestimmung genau beschrieben hat. Wenn die Software beispielsweise dazu eingesetzt werden soll/darf, um den anatomischen Aufbau in Vorbereitung auf eine OP oder eine Bestrahlungsplanung zu vermessen, dann ist (ohne einer dezidierten Risikoanalyse vorgreifen zu wollen) bei einem Softwarefehler eine schwere Verletzung denkbar. Das Softwaresystem wäre folglich Klasse C. D.h. aber nicht, dass alle Komponenten dieses Systems Klasse C wären. Welche das sind, muss in der Architektur beschrieben sein (IEC 62304 Kapitel 5.3).

Eine geschätzte Mitarbeiterin eines Medizintechnikherstellers hat mich auf einen Blogbeitrag aufmerksam gemacht, in dem der Autor zu folgendem Schluss kommt:

„The more you have to rely on software to treat the patient, to monitor its vital constants or to give a diagnosis, the higher the class.”

Was halten Sie davon? Die Einschätzung, dass die Klasse umso höher sei, je größer die Abhängigkeit von dem Produkt, halte ich für problematisch. Der Grad der Abhängigkeit hat Auswirkungen auf die Wahrscheinlichkeit, dass etwas passiert, aber nicht auf den Schweregrad. Für die Sicherheitsklassifizierung nach EN 62304 ist aber nur der maximale Schweregrad relevant.

Weiter heißt es in einem Kommentar zu dem Blogbeitrag im Kontext PACS:

That kind of software is class B because it is not used alone in the diagnosis. It is always inserted in a chain of decisions for example, assessment by pairs, biopsy … The software in its environment can not be the cause of a severe injury. There are always other measures of protection to prevent a problem if it is buggey or crashes.

Der Einschätzung, dass SW eines PACS-Viewers Klasse B sei, kann ich ebenfalls nicht folgen. Natürlich kann eine Rechts-Links-Vertauschung zu einer fehlerhaften oder verzögerten Behandlung (OP, Bestrahlung) führen. Das ist ja oft genug vorgekommen. Dass PACS Klasse IIb sind, dürfte ebenfalls ein Indiz sein. Die Tatsache, dass es „measures of protection to prevent“ gibt, reduziert nur die Wahrscheinlichkeit und rechtfertig daher nicht eine andere Klassifizierung als C.

3. Sicherheitsklassen von Komponenten

Es ist nicht Ihre Aufgabe als Entwickler(in), die Sicherheitsklassifizierung der Software (Klassen A, B, C gemäß IEC 62304) durchzuführen. Ich schreibe das, weil mich regelmäßig Software-Ingenieure fragen, wie sie dabei vorgehen sollen.

Die Antwort auf die Frage nach der “richtigen” Sicherheitsklasse ergibt sich ausschließlich aus der Risikoanalyse. Nur durch eine Risikoanalyse, idealerweise eine Fehlerbaumanalyse (Fault Tree Analysis, FTA), kann man herausfinden, zu welchen Schäden eine fehlerhafte Softwarekomponente führen kann. Das Ergebnis hängt sehr vom Nutzungskontext ab. Von den Anwendern, der Art der Benutzung usw. Ohne Kenntnis dieses Kontexts können Sie keinesfalls eine Sicherheitsklasse festlegen.

Risikoanalyse ist ein Teamsport: Der Risikomanager, der Experte für medizinische Folgen (Arzt), der Experte für den Anwendungskontext (z.B. Pflegekraft, Arzt, Patient) und die “Techniker” zusammen können diese Einschätzung vornehmen.

Um es ganz klar zu sagen: Einem Stück Software lässt sich niemals per se eine Sicherheitsklasse zuweisen. Weder einem Softwaresystem, noch eine dll oder sonstige Komponente haben eine fixe Sicherheitsklasse.

Lassen Sie mich wissen (z.B. via Webformular), wenn ich Ihnen bei der Sicherheitsklassifizierung helfen kann. Das tue ich gerne, schnell, vertraulich und meist sogar kostenlos.

Typische Missverständnisse und Fehler bei den Sicherheitsklassen

Die Sicherheitsklassifizierung von Software gemäß IEC 62304 ist immer wieder ein Thema bei meinen Seminaren, Inhouse-Workshops und Beratungen. Die Teilnehmer bzw. Firmen sind von dem Wunsch beseelt, die Sicherheitsklasse möglichst zu senken.

Annahme, die Sicherheitsklassen entsprächen dem Level of Concern

In der Tat scheinen sich die Definitionen von Sicherheitsklassen und Levels of Concern zu decken. Allerdings haben die Levels of Concern im Gegensatz zu den Sicherheitsklassen das Ziel, den Umfang der einzureichenden(!) Dokumentation zu steuern, nicht(!) der zu erstellenden.

Annahme, die Sicherheitsklasse ließe sich aus MDD Klasse ableiten

Eine der Argumentationen, die ich dann höre lautet wie folgt: Das Produkt ist ja nur Klasse I, d.h. die Software kann nicht Klasse C sein. Das stimmt in dieser Form nicht. Es gibt Produkte der Klasse I, die bei Fehlverhalten im ungünstigsten Fall zu einer schweren Verletzung führen. Das „im ungünstigsten Fall“ ist eine Aussage zur Wahrscheinlichkeit und damit zum Risiko. Die Sicherheitsklassifizierung berücksichtigt aber keine Wahrscheinlichkeiten. Daher ist sie eine Sicherheits- und keine Risikoklassifizierung.

Annahme, man könne bei Klasse B viel Dokumention sparen

Die nächste Annahme besteht darin, dass man bei Klasse B deutlich weniger machen/dokumentieren müsse. Auch das stimmt nur sehr bedingt. Im Vergleich zu einer Klasse C spart man sich nur das detailliertere Design – das keinesfalls bis auf Methoden- oder gar Methodensignaturebene erfolgen muss – und die dynamischen Komponententests. Aber mit Verlaub: Welche Entwicklungsabteilung, die auch nur einen Hauch an Professionalität hat, wird auf Unit-Tests verzichten?

Klassifizierung durch die Entwicklungsabteilung

Einen weiteren Fehler beobachte ich darin, dass das Software-Entwicklungsteam die Sicherheitsklasse bestimmt. Eine Software hat per se keine Sicherheitsklasse. Diese ergibt sich im Sinne einer FTA durch eine Analyse der Folgen eines nach außen „sichtbaren“ Gerätefehlers und der Analyse wie ein PESS (programmierbares elektrisches Subsystem) zu solch einem Gerätefehler beitragen kann. Die Sicherheitsklasse bestimmen also Risikomanager und Systemarchitekt, aber nicht die Software-Entwicklungsabteilung.

In Architektur nicht nachvollziehbare Segregation

Was mir weiter auffällt, ist eine eher „legere“ Begründung, weshalb einzelne Komponenten eines Softwaresystems eine niedrigere Sicherheitsklasse als das Softwaresystem insgesamt haben. Ohne eine dokumentierte, der Realität entsprechende Architektur lässt sich das überhaupt nicht argumentieren.

Software ist zu 100% fehlerhaft

Oft gibt es Diskussionen darüber, wie es sein kann, dass man im Rahmen der Risikoanalyse mit Wahrscheinlichkeiten arbeiten darf, man innerhalb der Software (gemäß IEC 62304) aber immer von 100% ausgehen müsse. Eine gute Frage!

Ein Risiko ist definitionsgemäß die Kombination aus Schweregrad und Wahrscheinlichkeit eines Schadens. Die IEC 62304 kennt in der Tat keine Wahrscheinlichkeiten, sondern nur die Sicherheitsklassen A (keine Verletzung möglich) bis C (schwere Verletzung oder Tod möglich).  Natürlich ist die Wahrscheinlichkeit eines Softwarefehlers nicht 100%. Die IEC 62304 will auch gar nicht die Risiken diskutieren. Sie will vielmehr die Hersteller dabei unterstützen, den Aufwand für die Dokumentation und das Testen von Software auf die sicherheitskritischen Bereiche der Software zu konzentrieren. Und dieser Aufwand soll nur von der Sicherheitsklasse, also den möglichen Folgen eines Fehlers innerhalb der Software, und nicht von der Wahrscheinlichkeit abhängen. Mehr sagt die IEC 62304 nicht.

Im Rahmen einer Risikoanalyse (z.B. auf FMEA oder FTA basierend) kann man durchaus auch andere Wahrscheinlichkeiten als 100% annehmen. Auch innerhalb der Software! Es sind zwei verschiedene Philosophien, die sich nicht gegenseitig verbieten.

Annahme, Sicherheitsklasse habe etwas mit direkten und indirekten Schäden zu tun

Auch bei meinem Treffen mit den benannten Stellen diskutierten wir darüber. So ging es darum, ob der Grad der Direktheit, in dem eine Software zu einem Schaden beitragen kann, eine Auswirkung auf die Sicherheitsklasse hat.

Beispielsweise hat die Software eines Defibrilators einen hohen Grad der Direktheit, die Software zur Berechnung von Wechselwirkungen von Medikamenten einen niedrigeren Grad. Ein Auditor meinte, er würde darauf achten, dass die Medizinproduktehersteller die Ärzte nicht zu „Alibi man in the middle“ erklären, die in Wirklichkeit gar nicht richtig überblicken würden, was das Gerät macht.

Ich stimme zu, dass es unterschiedliche Grade der Direktheit gibt. Dass diese aber eine Auswirkung auf die Sicherheitsklasse haben, möchte ich hinterfragen. Der Grad der Direktheit hat eine Auswirkung auf die Wahrscheinlichkeit, dass ein Software-Fehler zu einem Schaden führt. Aber genau diese Wahrscheinlichkeit soll bei der Sicherheitsklassifizierung nicht betrachtet werden, sondern nur der Schweregrad.

Weshalb die ganze Diskussion um die Sicherheitsklassifizierung weitgehend absurd ist und wie Sie auch bei Sicherheitsklasse C eine schlanke, hilfreiche und gesetzeskonforme (IEC 62304, FDA) Software-Akte erstellen, verrate ich Ihnen beim „Kompaktseminar ‚medizinische Software’“. Hier werde ich Ihnen alle Fragen persönlich beantworten.

Mehr zum „Kompaktseminar ‚medizinische Software’“

Wie Sie tricksen können

Die IEC 62304 definiert ziemlich klar die verschiedenen Sicherheitsklassen für Software. Sie legt auch fest, dass die Sicherheitsklassen durch Hardware-Maßnahmen um eine Klasse von C auf B bzw. von B auf A reduziert werden kann. Trotzdem berichten mir die benannten Stellen, wie Hersteller einen „Gestaltungsspielraum“ suchen und finden.

Stellen Sie sich dazu folgendes Szenario vor:

Szenario 1: Maßnahme vor Sicherheitsklassifizierung

Ein Hersteller bringt ein Medizinprodukt in Verkehr, bei dem durch ein spezielles Design in Form einer Hardware ein Softwarefehler zu keinerlei Schäden für Patienten und Anwender führen kann. Die Software hat dann definitionsgemäß Sicherheitsklasse A.

Szenario 2: Maßnahme nach Sicherheitsklassifizierung

Ein Hersteller bringt das identische Medizinprodukt in Verkehr. Dieses Mal stellt er aber fest, dass ein Softwarefehler zu einem schweren Schaden führen kann. Die Software ist also Klasse C. Um das Risiko zu minimieren, wählt er dieselbe Maßnahme in Form einer Hardware, die einen Schaden für Patienten und Anwender ausschließt. Der Hersteller darf deshalb die Sicherheitsklasse der Software auf B reduzieren.

Reihenfolge entscheidend bei Klassifizierung gemäß IEC 62304?

Ist also bei der Festlegung der Software-Sicherheitsklassen gemäß IEC 62304 die Reihenfolge entscheidend und damit nur die Wahl der Argumentation? Die Vertreter der benannten Stellen, die bei mir zu Gast waren, haben sich auf folgende Linie geeinigt:

Wenn eine Maßnahme so offensichtlich ist, dass sie jeder Absolvent eines Studiums der Elektrotechnik oder des Maschinenbaus so wählen würde, kann man gemäß Szenario 1 argumentieren. Andernfalls handelt es sich um eine wirklich Maßnahme, die man im Übrigen auch in der Risikoanalyse explizit aufgeführt sehen will.