IVD-Software richtig qualifizieren und klassifizieren

Der Begriff IVD-Software ist nicht klar definiert, obwohl Software als IVD (In-vitro-Diagnostikum) oder als Zubehör zu einem IVD immer häufiger zum Einsatz kommt.

Wann Software als IVD zu klassifizieren ist, in welche Liste bzw. Klasse die Software fällt und was man bei der Sicherheitsklassifizierung nach IEC 62304 beachten sollte, beschreibt dieser Beitrag.

0. Klassifizierung von IVD-Software

Es gilt drei Klassifizierungen von IVD-Software zu unterscheiden:

1. Klassifizierung von Software als IVD, als Medizinprodukt oder als Zubehör
2. Risiko-Klassifizierung gemäß IVD-Richtlinie bzw. IVDR
3. Sicherheitsklassifizierung der Software nach IEC 62304

1. Klassifizierung von Software als IVD

a) Mögliche Fälle

Bei „IVD-Software“ gilt es mehrere Varianten zu unterscheiden:

1. Eigenständiges In-vitro-Diagnostikum d.h. die Software ist selbst ein IVD gemäß IVDD bzw. IVDR
2. Software als Zubehör zu einem IVD
3. Software, die zwar im IVD-Kontext genutzt wird, die aber unter die MDD/MDR fällt
4. Embedded Software, d.h. Software, die Teil eines IVDs ist
5. Software, die ein (Hardware-)IVD steuert oder dessen Anwendung beeinflusst
6. Schließlich Software, die kein Medizinprodukt ist

b) Regelwerk der MEDDEV 2.1/6 zu IVD Software

Die EU Leitlinie MEDDEV 2.1/6 regelt, wie IVD-Software gemäß den o.g. Fallunterscheidungen klassifiziert werden muss. Allerdings gilt diese Leitlinie für die IVD-Richtlinie IVDD und verliert mit Gültigkeitsbeginn der IVDR (26. Mai 2022) bzw. nach Ablauf entsprechender Übergangsfristen ihre Anwendbarkeit. Die MEDDEV 2.6/1 wird somit durch die Leitlinie MDCG 2019-11 abgelöst, die den Bezug zur MDR und IVDR herstellt und bestehende Konzepte aufgreift. (Lesen Sie mehr dazu mehr in Absatz c)

Fallunterscheidung 1: Fällt die IVD-Software unter eine EU-Richtlinie?

Im ersten Schritt untersucht die MEDDEV, ob die Software überhaupt unter eine der Medizinprodukte-Richtlinien fällt und verweist dabei auf eine weitere Abbildung. Lesen Sie dazu mehr im Beitrag „Software als Medizinprodukt“.

Fallunterscheidung 2: Expertensystem?

Der zweite Schritt untersucht, ob

1. ein Expertensystem beteiligt ist, welches Informationen liefert, die
2. unter den Anwendungsbereich des Begriffs In-vitro-Diagnostikum fallen.

Die MDCG Guidance 2019-11 verwendet die Fallunterscheidung „Expertensystem“ nicht mehr. Damit zieht man sich auf die Definition des Begriffs In-vitro-Diagnostikum zurück, was mit der erweiterten IVD-Definition gemäß IVDR konsistent ist, da diese nun explizit „Software“ als solche mit einschließt.

D.h. die Frage bei diesem 2. Schritt, ob die Software unter den Anwendungsbereich der IVDR fällt, wäre im folgenden Fall zu bejahen:

Die Software ist alleine oder in Kombination dafür vorgesehen, für/bei In-Vitro-Untersuchungen genutzt zu werden, um Körperflüssigkeiten oder Gewebe außerhalb des Körpers zu untersuchen und um dabei Informationen zu liefern

1. über physiologische oder pathologische Prozesse oder Zustände,
2. über kongenitale körperliche oder geistige Beeinträchtigungen,
3. über die Prädisposition für einen bestimmten gesundheitlichen Zustand oder eine bestimmte Krankheit,
4. zur Feststellung der Unbedenklichkeit und Verträglichkeit bei den potenziellen Empfängern,
5. über die voraussichtliche Wirkung einer Behandlung oder die voraussichtlichen Reaktionen darauf oder
6. zur Festlegung oder Überwachung therapeutischer Maßnahmen.

Software analysiert offensichtlich nie direkt die Körperflüssigkeiten oder Gewebeproben, sondern Daten. Bei der Fallunterscheidung geht es jedoch um die Zielstellung dieser Analyse.

Diese Software lässt sich in zwei Typen unterscheiden:

1. Software, die über die Hardware mit den Proben zum Zweck der Analyse interagiert, wie das z.B. bei Treibern oder bei der Erfassung der Rohdaten der Fall wäre.
2. Software, die Rohdaten oder andere Daten mit einer der o.g. Zielstellungen sekundär weiterverarbeitet und analysiert.

Fallunterscheidungen 3 und 4: Woher stammen die Daten?

Bei den Schritten drei und vier unterscheidet die MEDDEV die Datenquellen:

Datenquelle	Relevante Richtlinie / Verordnung
Ausschließlich IVD(s) – gemäß IVDD / IVDR	IVDD / IVDR
Ausschließlich MD(s) – gemäß MDD / MDR	MDD / MDR
Von IVD(s) und von MD(s)	IVDD / IVDR

Diese Fallunterscheidung ist bemerkenswert, da die Datenquelle entscheidend ist und nicht (nur) die Zweckbestimmung. Dies ist teilweise nachvollziehbar, weil sich die Zweckbestimmungen von Medizinprodukten (MDs) und In-vitro Diagnostika (IVDs) überlappen:

IVDR	Überlappender Teil in der MDR
(a) über physiologische oder pathologische Prozesse oder Zustände,	Untersuchung, Ersatz oder Veränderung der Anatomie oder eines physiologischen oder pathologischen Vorgangsoder Zustands,
(b) über kongenitale körperliche oder geistige Beeinträchtigungen;	Diagnose, Überwachung, Behandlung, Linderung von oder Kompensierung von Verletzungen oder Behinderungen,
(c) über die Prädisposition für einen bestimmten gesundheitlichen Zustand oder eine bestimmte Krankheit,	Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten,
(d) zur Feststellung der Unbedenklichkeit und Verträglichkeit bei den potenziellen Empfängern
(e) über die voraussichtliche Wirkung einer Behandlung oder die voraussichtlichen Reaktionen darauf oder
(f) zur Festlegung oder Überwachung therapeutischer Maßnahmen.

Die Klassifizierung der Software gemäß MEDDEV anhand der Datenquellen mag zwar einfacher sein, sie ist jedoch nicht immer trennscharf und auch nicht immer hilfreich. Weshalb soll ein Produkt, das der identischen Diagnose dient, abhängig von den Datenquellen unterschiedlich behandelt werden? Weshalb verlangt der Gesetzgeber im einen Fall eine klinische Bewertung und im anderen Fall eine Leistungsbewertung?

Während In-vitro-Diagnostika, wie der Name impliziert, eher der Diagnose dienen, sollte bei therapeutischen Zielsetzungen die MDR gelten und zwar unabhängig von der Datenquelle. Die Unterscheidung nach der Datenquelle erscheint eher bei den diagnostischen Zielsetzungen als sinnvoll.

Fallunterscheidungen 5. und 6.: Zubehör?

Leider gibt die MEDDEV weder zum fünften noch zur sechsten Fallunterscheidung Hilfestellung.

Standalone Software kann auch ein Zubehör zu einem IVD-Gerät sein. Den Begriff Zubehör definiert die IVD-Richtlinie wie folgt:

Ein Beispiel für eine Software, die als Zubehör zu einem In-vitro-Diagnostikum zählt, wäre eine Software zum Kalibrieren eines IVDs.

Fazit zur Anwendbarkeit der MEDDEV 2.1/6 unter der IVDR

Durch die Ergänzung von „Software“ in der Definition eines In-vitro-Diagnostikums in der IVDR erscheint die MEDDEV 2.1/6 auf den ersten Blick obsolet. Die Leitlinie liefert jedoch den Herstellern wertvolle Wegweiser, in Grenzfällen zwischen IVDR und MDR und insbesondere dann, wenn bei der Klassifizierung von Software durch die „weite Entfernung“ vom Patienten die Datenquelle außer Acht gelassen wird.

Dies kann z.B. der Fall sein, wenn eine Software als Webservice angeboten wird, die genetische Daten auf Prädisposition von genetisch bedingten Erkrankungen untersucht. Dass die genetischen Daten hierbei ursprünglich von einer Speichel- oder Blutprobe stammen, anschließend von irgendeinem Laboratorium über Hoch-Durchsatz-Sequenzierung die Daten entstanden sind, diese dann an ein medizinisches Laboratorium und von dort an den zuständigen Arzt weitergereicht wurden und dieser die Daten in den Cloudserver lädt, führt möglicherweise zu einer Fehlinterpretation der Software als Medizinprodukt unter MDR.

Solche oder ähnliche Fälle können mittels Durchlaufen der Flussdiagramme der MEDDEV 2.1/6 auch unter der IVDR vermieden werden. Es wird jedoch auch neue Fragestellungen geben, die aufgrund der mit der IVDR in Anhang VIII neu eingeführten Klassifizierungsregeln in Erscheinung treten werden.

In einer älteren Version dieses Artikels haben wir uns ein Update des Leitfadens gewünscht, der auch Beispiele zur Klassifizierung enthält. Dies ist nun in Form der MDCG 2019-11 geschehen. Diese neue Guidance diskutiert der folgende Absatz.

c) Regelwerk der MDCG Guidance  zu IVD Software

Das am 11. Oktober 2019 veröffentlichte Dokument der Medical Device Coordination Group (MDCG) mit dem Titel Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR (MDCG 2019-11) löst unter MDR und IVDR die MEDDEV 2.1/6 ab und stellt somit die wesentliche Entscheidungshilfe dar zur Einschätzung ob es sich bei einer im Zusammenhang mit einer IVD-Untersuchung eingesetzten Software um eine IVD-Software gemäß IVDR handelt.

Diese neue Leitlinie dient einerseits der Einschätzung (Qualifizierung), ob Software-Produkte unter den Anwendungsbereich der EU-Verordnungen für Medizinprodukte (2017/745 – MDR und 2017/746 IVDR) generell fallen und andererseits der Einstufung (Klassifizierung) unter welcher der beiden genannten Verordnungen die Software konformitätsbewertet werden sollte.

Entsprechend definiert sie auch den neu eingeführten Begriff Medical Device Software (MDSW) wie folgt:

Lesen sie mehr zur Einstufung, ob Software unter die EU-Medizinprodukt-Verordnungen fällt in unserem Hauptartikel zu Software als Medizinprodukt.

Nachdem geklärt ist, ob es sich um eine MDSW handelt, stellt das Dokument drei weitere Entscheidungsfragen, um die MDSW als IVD MDSW unter IVDR oder MD MDSW unter IVDR zu klassifizieren, welche sie in einem zweiten Flussdiagramm darstellt:

Die Frage 1 untersucht nun, ob die als MDSW qualifizierte Software anhand der IVD-Definition in den Anwendungsbereich der IVDR fällt. Kann diese Frage mit nein beantwortet werden, ist sie ausschließlich unter der MDR zu betrachten.

Fällt die Software jedoch unter die IVD-Definition stellt sich die zweite Frage, ob die Daten ausschließlich von einem IVD-Medizinprodukt stammen. Falls ja fällt sie unter die IVDR und falls nein weiter zu Frage 3. Interessant ist hierbei, dass die MDCG hierbei ausdrücklich von IVD-Medizinprodukten spricht. Ob man hierbei bewusst nicht auf den Umstand eingeht, dass IVD-Software in vielen Anwendungsfällen auch Daten nutzt, die aus als „for research use only“ (RUO) gekennzeichneten Produkten stammen entzieht sich unserer Kenntnis.

Die dritte Frage untersucht ob die Software sowohl Daten aus IVD-Quellen, als auch aus anderen Quellen nutzt und damit ob die Zweckbestimmung wesentlich durch IVD-Datenquellen erreicht wird? Falls Ja, fällt sie unter die IVDR, falls nein unter die MDR. Zwar lässt sich aus der grafischen Darstellung vermuten, dass man hier mit IVD-Datenquellen auch die zuvor geschilderten RUO-Quellen mit einbezieht, jedoch spricht der Text erneut von IVD-Medizinprodukten was diese spezielle Frage unbeantwortet lässt.

Fazit zur MDCG 2019-11 in Hinblick auf IVD-Software

Diese neue Leitlinie schließt nun die in der vorigen Version dieses Artikels diskutierte Lücke der MEDDEV 2.6/1 zur IVDR. Sie liefert zumindest für Software-Produkte, die klar unter die IVD-Definition fallen oder ausschließlich Daten von IVD-Medizinprodukten verarbeiten in einer Weise, die über Grundfunktionen wie speichern, archivieren, etc. hinaus gehen eine eindeutige Vorgabe zur Anwendung der IVDR. Für Software-Produkte, die sowohl Daten von IVD-Quellen als auch von „klassischen“ Medizinprodukten verarbeiten, wird es noch Uneinigkeiten geben können. Als Entscheidungshilfe sind in Anhang II der Leitlinie Beispiele ergänzt, die für die jeweiligen Entscheidungsschritte zutreffen.

Für den letzten „kniffligen“ Entscheidungsschritt (Nr. 3) bei gemischten Datenquellen wurde als „IVD MDSW“ das klassische Beispiel der Pränataldiagnostik herangezogen, welches unter der IVD-Richtlinie zur einzigen Erwähnung von Stand-Alone-Software geführt hat: Software zur Risikobestimmung einer Trisomie 21, die auch Ultraschall-Ergebnisse in den Algorithmus zur Risikobestimmung nutzt (Siehe auch Richtlinie 98/79/EG Anhang II Liste B). Dass man sich hier als Entscheidungshilfe eines über 20 Jahre alten Beispiels bedient ist zwar hilfreich, ein jüngeres Fallbeispiel würde dem Dokument hinsichtlich seiner Gebrauchstauglichkeit gut tun.

Etwas verstörend ist, dass der Begriff „Expertensystem“ ist zwar definiert ist, dieser jedoch weder für die Qualifizierung noch für die Klassifizierung von Software Verwendung findet. Daher ist diese Definition scheinbar nicht mehr für die Fallunterscheidung relevant und erweckt den Eindruck ein Überbleibsel aus der MEDDEV 2.6/1 zu sein. Sinnvoll betrachten wir die dadurch bedingte Konzentration auf die Begriffsdefinition eines In-vitro Diagnostikums und die Datenquelle als Entscheidungskriterien, ob eine Software unter der IVDR behandelt werden soll. Positiv zu bemerken sind einige Beispiele von IVD-Software-Klassifizierungen dargelegt sind, die eindeutig den Klassen A bis D zuordenbar sind.

Kritik

Leider adressiert der Leitfaden keine speziellen Fragestellungen wie zum Beispiel eine unter Artikel 5 der IVDR in einer Gesundheitseinrichtung hergestellte und in Betrieb genommene Software welche im Rahmen eines Laboratory Developed Test (LDT) eingesetzt wird. Gerade in solchen Fällen wird häufig auf „for research use only“ (RUO) gekennzeichnete Produkte zurückgegriffen, wodurch die MDCG Guidance eine Lücke offen lässt und nicht diskutiert wie in solchen Fällen zu verfahren ist.

Des weiteren sind häufige Fragestellungen bei Software-Anwendungen im IVD-Kontext nicht berücksichtigt, wie zum Beispiel eine Parametrisierung von Software, die der Hersteller dem professionellen Anwender, also dem medizinischen Labor überlassen möchte, damit dieser eigene Grenzwerte definieren kann. Ob dies seitens der MDCG ein dem Stand der Technik akzeptiertes vorgehen ist und eine Vorgabe, wer in solchen Fällen für die Erbringung des klinischen Nachweises zuständig ist – Labor oder Software-Hersteller wäre wünschenswert.

Wunschliste

Ein Update des Leitfadens sollte Grenzfälle zu den neuen Klassifizierungsregeln der IVDR Anhang VIII berücksichtigen und auch Beispiele nennen, um Fragen zu beantworten wie:

• Wie sind Warnungen von „Out-of-Range“ Werten zu bewerten? Ändert sich an dieser Einschätzung etwas, wenn dabei komplexe Abhängigkeiten zwischen Werten berücksichtigt werden?
• Welche Berechnungen und Umwandlungen von und zwischen Werten sind noch unkritisch?
• Welche Freiheitsgrade gibt es bei der Darstellung z.B. von Trendlinien und Korrelationen?
• In welche Klasse fallen Produkte, die nach vorangegangener Diagnose von Infektionserregern (durch ein unabhängiges IVD) Subtypen der Infektionserreger differenzieren?
• Auf was müssen Hersteller achten, wenn sie den Anwendern die Parametrierung und ggf. sogar ein Scripting erlauben?

An der Erstellung dieses Kapitels war Dr. Sebastian Grömminger beteiligt, IVD-Experte am Johner Institut.

2. Risiko-Klassifizierung von IVD-Software gemäß IVDR und IVDD

a) Risiko-Klassifizierung gemäß IVDD

Die IVD-Richtlinie (IVDD) definiert verschiedene Klassen von In-vitro-Diagnostika:

• Liste A beinhaltet die Produkte mit dem höchsten Risiko wie Blutgruppen-Tests und lebensbedrohliche Infektionskrankheiten
• Liste B beinhaltet die Produkte mit dem hohem individuellen Risiko bei falschem Ergebnis wie Tumormarker (konkret: PSA)
• Zusätzlich gibt es noch die Produkte zur Eigenanwendung und
• die sonstigen IVD

b) Risiko-Klassifizierung gemäß IVDR

Die IVDR unterscheidet die Klassen A bis D, wobei die Klasse A die unkritischen und die Klasse D die höchstkritischen Produkte umfasst. Die Autoren der IVDR bedienten sich hierbei der Vorgaben der GHTF bzw. mittlerweile IMDRF. Denn diese beschrieb bereits 2008 in ihrem Guidance Document “Principles of IVD Medical Devices Classification” (GHTF/SG1/N045:2008) eine entsprechende Klassifizierung.

Die IVDR enthält vergleichbar der MDR u.a. die folgenden Klassifizierungsregeln:

1.1. Die Anwendung der Klassifizierungsregeln richtet sich nach der Zweckbestimmung der Produkte.

1.2. Wenn das betreffende Produkt dazu bestimmt ist, in Verbindung mit einem anderen Produkt angewandt zu werden, werden die Klassifizierungsregeln auf jedes Produkt gesondert angewendet.

1.3. Zubehör für ein In-vitro-Diagnostikum wird unabhängig von dem Produkt, mit dem es verwendet wird, gesondert klassifiziert.

1.4. Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, wird derselben Klasse zugerechnet wie das Produkt. Ist die Software von anderen Produkten unabhängig, so wird sie für sich allein klassifiziert.

1.8. Wenn der Hersteller für ein Produkt mehrere Zweckbestimmungen angibt und das Produkt daher mehr als einer Klasse zuzuordnen ist, wird es in die höchste der Klassen eingestuft.

1.9. Für den Fall, dass für dasselbe Produkt mehrere Klassifizierungsregeln gelten, wird die Regel der Einstufung in die höchste dieser Klassen angewendet.

Quelle: IVDR, Anhang VIII

c) Bedeutung der Risiko-Klassifizierung

Die Klassifizierung wirkt sich nicht auf die Sicherheits- und Leistungsanforderungen aus, die die IVD-Geräte erfüllen müssen. Selbst bei einer Software der Klasse A (nicht verwechseln mit der Sicherheitsklasse A gemäß IEC 62304) müssen alle Anforderungen erfüllt sein wie:

• Software-Lebenszyklus (IEC 62304)
• Risikomanagement (ISO 14971)
• Gebrauchstauglichkeit (IEC 62366-1)
• IT-Sicherheit
• Verifizierung und Validierung

Die Klassifizierung entscheidet aber über die möglichen Konformitätsbewertungsverfahren. Bei IVD der Klasse A müssen die Hersteller keine benannte Stelle involvieren, d.h. eine Prüfung der Dokumente durch eine benannte Stelle ist nicht erforderlich. Auch benötigen die Hersteller kein zertifiziertes QM-System.

d) Typen an IVD-Software

Bei IVD-Software unterschieden wir bereits folgende Formen an standalone Software:

1. Eigenständiges In-vitro-Diagnostikum d.h. die Software ist selbst ein IVD gemäß IVDD bzw. IVDR
2. Zubehör zu einem IVD
3. Software, die zwar im IVD-Kontext genutzt wird, die aber unter die MDD/MDR fällt
4. Software, die kein Medizinprodukt ist

Daneben gibt es embedded Software, also Software, die Teil eines In-vitro-Diagnostikums ist. Diese Software wird jedoch nicht eigenständig klassifiziert, weshalb sich die folgenden Abschnitte auf die Klassifizierung von standalone Software konzentrieren können. Sie beschränken sich auch auf den Fall, dass die Software tatsächlich unter die IVD/IVDR fällt.

e) Anwendung der Klassifizierungsregeln

Die IVDR behandelt (im Gegensatz zur IVD-Richtlinie 98/79/EG) Software ausführlicher. Sie betont, dass die Zweckbestimmung für die Klassifizierung entscheidend ist und damit die Fragestellung, ob es die Software ist, die die klinische Aussage erlaubt. D.h. es ist entscheidend, ob die Spezifität und ggf. die Sensitivität des Analyten erst durch die Software hergestellt wird.

Beispiele für solche Software sind bioinformatische Softwareprodukte, die allgemeine genetische Daten einer Patientenprobe aus einer Hochdurchsatz-Sequenzierung von DNA-Proben mit Referenzdaten vergleichen, mit der Zielstellung z.B.

• festzustellen, ob eine Krankheit vorliegt oder
• einen bestimmten physiologischen Zustand zu diagnostizieren oder analysieren oder
• Stadien einer Krebserkrankung einzuteilen.

D.h. solche Software-Produkte fallen je nach Klassifizierungsregel in Klasse B, C oder D.

IVD-Software in „Risikoklasse“ A?

Der Aussage mancher Auditoren, IVD-Software würde immer in Klasse A fallen, weil Software Patienten nie direkt schaden könne oder weil die Software selbst nichts könne, muss widersprochen werden.

Sofern eine standalone Software Daten von einem bestimmten Instrument auswertet und nichts Analytenspezifisches macht, also vollkommen unabhängig vom IVD-Assay Daten auswertet (z.B. ohne assayspezifische hinterlegte Grenz- oder Qualitätswerte), kann sie derselben Klasse wie das Instrument zugeordnet werden (gemäß Durchführungsvorschrift 1.4). Das wäre einer der wenigen Fälle, in denen eine IVD-Software in Klasse A fallen kann.

Risikoklassen B, C und D

Falls die IVD-Software jedoch assayspezifische Auswertungen vornimmt, muss sie derselben Klasse wie der des Assays zugeordnet werden. Schließlich beeinflusst sie das Ergebnis und damit die Anwendung.

Können verschiedene Assays mit der Software ausgewertet werden, sind auch die Durchführungsregeln 1.8 und 1.9 besonders zu beachten (Klassifizierung in die höchste Klasse der betreffenden Assays!)

Somit ist es eine strategische Entscheidung, ob man Software in steuernde Elemente und auswertende Elemente trennt, um sie unterschiedlich klassifizieren zu können.

An der Erstellung dieses Kapitels war Dr. Sebastian Grömminger beteiligt, IVD-Experte am Johner Institut.

3. IVD: Software-Sicherheitsklassifizierung gemäß IEC 62304

a) Fragestellung: A, B oder C?

Ein Point-of-Care-Gerät misst „übliche“ Parameter wie pH, pCO2, Glukose, Kalium usw. Nun gibt es Diskussionen darüber, wie die Software zu klassifizieren sei. A, B oder C?

Ein Team argumentiert für Sicherheitsklasse B, weil keine schwere Verletzung möglich sei. Schließlich sei das Messergebnis des IVD-Geräts nur einer von vielen Parametern für eine Therapie – eben die richtige oder die falsche oder eine richtige aber verspätete. Zudem würden im Laborgerät regelmäßig Kalibrierungs- und Kontrollzyklen gefahren.

Ein anderes Team argumentiert für Sicherheitsklasse C, weil es in einem unwahrscheinlichen Fall tatsächlich eine Patientenschädigung geben könnte. Die Ärzte als „risikominimierende Maßnahme“ nehmen sie dabei nicht in Betracht.

Wie ist nun diese Software des IVDs gemäß IEC 62304 zu klassifizieren?

b) Vorüberlegungen: Besonderheiten von IVD

Wie bei allen IVD-Geräten, genauer gesagt Messwerten, gibt es im Gegensatz zu anderen Geräten keine direkte Möglichkeit einer Schädigung. Keine Quetschung, keine Verstrahlung, kein elektrischer Schlag usw. Die Messwerte können „nur“ dazu führen, dass Patienten falsch, verzögert oder gar nicht behandelt werden – was je nach Kontext der Anwendung fatale Folgen haben kann.

Diese „äußere Ursachenkette“, also die Ursachenkette vom falschen oder fehlenden Messwert, ist sehr schwer abzuschätzen. Besonders schwer abzuschätzen sind die Wahrscheinlichkeiten. Beispielsweise die Wahrscheinlichkeit, dass ein Arzt tatsächlich aufgrund eines falschen oder fehlenden Messwerts falsch behandelt.

Leider betrachtet die IEC 62304:2006 diese Wahrscheinlichkeiten überhaupt nicht. Damit kann bei „ausreichend kritischen“ Patienten im unwahrscheinlichsten Fall etwas Schlimmes passieren. Und damit ergibt sich die Sicherheitsklasse C. Die IEC 62304:2006 + A1:2015 gewährt hierbei mehr Optionen.

Die Kalibrier- und Kontrollzyklen ändern daran wahrscheinlich nichts, sie reduzieren nur die Wahrscheinlichkeit, dass ein Messwert falsch oder gar nicht angezeigt wird. Wahrscheinlichkeiten sind aber für die Sicherheitsklassifizierung irrelevant – zumindest bei der „alten“ IEC 62304.

c) Antwort: Die Zweckbestimmung entscheidet

Die Sicherheitsklasse bei IVD hängt v.a. von der Zweckbestimmung ab, die wiederum die Patienten bzw. deren Gesundheitszustand bzw. Krankheit festzulegen hat. Daraus ergeben sich der maximale Schweregrad des Schadens, der durch einen Softwarefehler verursacht werden kann – weitgehend unabhängig von der Wahrscheinlichkeit – und damit die Sicherheitsklasse der Software gemäß IEC 62304.

Hierbei spielt zudem die untersuchte Patientenpopulation eine entscheidende Rolle z.B. Einsatz als Screening-Test in der überwiegend gesunden Population oder ein Bestätigungstest auf Basis von Risikofaktoren oder Voruntersuchungen und somit an einer vorwiegend bereits erkrankten (Hoch-Risiko-)Population. Daher sind entsprechende Leistungsparameter wie z.B. der positive und der negative prädiktive Wert unbedingt in der entsprechenden Bevölkerungsgruppe zu betrachten, damit die Wahrscheinlichkeit, dass eine untersuchte Person auch das korrekte Ergebnis erhält, korrekt berechnet wird.