IVD Software-Hersteller aufgepasst

Dieser Artikel beschreibt die Anforderungen der In-vitro Diagnostic Regulation IVDR an die Entwicklung und Dokumentation der Software.

Die Anforderungen betreffen sowohl Software, die Teil eines IVDs ist (embedded Software), als auch Software, die selbst ein IVD darstellt (standalone Software).

Ebenso finden Sie in diesem Beitrag einen Vergleich der Anforderungen der MDR und der IVDR an die Software.

1. IVD > IVDR: Die wichtigsten Änderungen im Überblick

Die alte IVD Richtlinie stellt nahezu keine expliziten Anforderungen an die Entwicklung und Dokumentation von Software. Das hat sich mit der IVDR grundlegend geändert. Die wichtigsten Änderungen diesbezüglich sind:

1. Die IVDR erwähnt Software in der Definition des Begriffs „IVD“ ausdrücklich.
2. Zudem verlangt die IVDR Software-Lebenszyklusprozesse einschließlich der Verifizierung und Validierung der Software.
3. Die IVDR fordert, dass die Hersteller die IT-Sicherheit ihrer Produkte gewährleisten.
4. Die IVDR stellt Anforderungen an die Dokumentation der Software.
5. Auch stand-alone IVD-Software muss über eine Unique Device Identification verfügen.
6. Es gibt eine spezielle Klassifizierungsregel für Software.

Im Folgenden finden Sie weitere Informationen zu diesen Aspekten.

2. Definition: IVDR schließt Software mit ein

Die Definition des Begriffs „In vitro Medical Device“ hat sich im Vergleich zur IVD leicht geändert:

In fett sind die Änderungen dargestellt. Im Kontext von Software sind auch die erweiterten Zweckbestimmungen interessant, die nun die „Prädisposition für einen bestimmten gesundheitlichen Zustand oder eine bestimmte Krankheit“ und die „Festlegung oder Überwachung therapeutischer Maßnahmen“ (z.B. Medikamente) ausdrücklich mit einschließen.

3. Allgemeines Sicherheits- und Leistungsanforderungen der IVDR

a) Software-Entwicklung nach Stand der Technik

Die IVDR stellt bezüglich Software die folgende Anforderung (wortgleich mit der MDR):

„Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.“

Die meisten Hersteller dürften versuchen, durch Einhaltung der IEC 62304 die Konformität nachzuweisen. Allerdings geht die Norm nicht auf die Validierung ein. Auch sind die Anforderungen der Norm bezüglich IT-Sicherheit sehr rudimentär.

b) Zuverlässigkeit, „Erstfehlersicherheit“

Die IVDR dehnt die Forderung an die Zuverlässigkeit und Robustheit explizit auch auf stand-alone Software aus. Sehr an die IEC 60601-1 und deren Konzept der Erstfehlersicherheit erinnert diese neue Anforderung:

„Für den Fall des Erstauftretens eines Defekts sind geeignete Vorkehrungen zu treffen, um sich daraus ergebende Risiken oder Leistungsbeeinträchtigungen auszuschließen oder sie so weit wie möglich zu verringern.“

c) Besonderheiten mobiler Plattformen

Genau wie die MDR springt die IVDR auf den Zug auf, spezielle Anforderungen an mobile Plattformen zu spezifizieren. Deren Besonderheiten müssen die Hersteller betrachten:

• Größe und Kontrastverhältnisse von Bildschirmen
• Nutzungsumgebung wie die physikalische Umgebung (Helligkeit, Lautstärke)
• Betriebssysteme

Das „Betrachten“ bezieht sich wahrscheinlich auf die Spezifikation der Software-Anforderungen, auf das Risikomanagement und die Gebrauchstauglichkeit.

d) Anforderungen an die IT-Sicherheit und die Netzwerke

Ohne konkret zu werden, verlangt die IVDR von den Herstellern, die Anforderungen an die Hardware, an die Netzwerk-Charakteristiken und an die IT-Sicherheit festzulegen. Bei der IT-Sicherheit geht die IVDR nur auf den Schutz vor unbefugtem Zugriff ein. Die IT-Sicherheit auf diesen Aspekt zu reduzieren, ist sicher fragwürdig.

e) Anforderungen an die Gebrauchsanweisungen

Diese Mindestanforderungen an die IT-Sicherheitsmaßnahmen, an die Netzwerke und an die Hardware müssen die Hersteller in die Gebrauchsanweisung mit aufnehmen.

f) Erste Zusammenfassung

Trägt man die Anforderungen zusammen, die die IVDR an Software stellt, fällt  auf: Mit Ausnahme der Wartbarkeit fordert die IVDR alle Software-Qualitätskriterien ein, die die ISO 25010 auflistet. Nur gelingt der IVDR das nicht so strukturiert und konsistent.

4. Dokumentation der Software konform IVDR

Die IVD kannte nur den Anhang I mit den „grundlegenden Anforderungen“. Hingegen unterscheidet die IVDR einen Anhang I mit den „allgemeinen Sicherheits- und Leistungsanforderungen“ und einen Anhang II mit den Anforderungen an die technische Dokumentation.

Diese Dokumentation der Software muss umfassen:

• Darlegung der Entwicklungsstufen
• Beschreibung der Software und einen Überblick über das Software-System (was auch immer damit gemeint ist)
• Beschreibung der Datenauswertung insbesondere der Software-Algorithmen
• Zusammenfassung der Software-Verifizierung und Software-Validierung. Diese müssen „hausintern und in einer tatsächlichen Verwenderumgebung“ erfolgen und dabei verschiedene Hardware-Konfigurationen und mögliche Betriebssysteme berücksichtigen.

5. Klassifizierung von IVD Software

Den Herstellern von IVD Software bleibt zumindest eine Klassifizierungsregel wie in der MDR die Regel 11 erspart. Die einzige Software-spezifische Regel lautet:

„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.“

Dass die IVDR für Software keine weiteren Regeln aufstellt und somit die Regeln spezifisch für die Analyte festlegt, ist konsequent.

6. UDI

Die Anforderungen an die Unique Device Identification sind wortgleich mit denen der MDR.

 7. Vergleich der Anforderungen der MDR und der IVDR an die Software-Entwicklung

Die Anforderungen der MDR und IVDR an die Entwicklung von Software sind nicht identisch. Im Folgenden stellt Ihnen das Johner Institut die wichtigsten Gemeinsamkeiten und Unterschiede vor.

a) „Grundlegende Anforderungen“

Die grundlegenden Anforderungen, die jetzt allgemeine Sicherheits- und Leistungsanforderungen heißen, sind bei der MDR und IVDR buchstabengleich:

MDR	IVDR
Grundlegende Anforderungen (Anhang I)
14.2. Die Produkte werden so ausgelegt und hergestellt, dass folgende Risiken ausgeschlossen oder so weit wie möglich reduziert werden: […] d) Risiken im Zusammenhang mit der möglichen negativen Wechselwirkung zwischen Software und der IT-Umgebung, in der sie eingesetzt wird und mit der sie in Wechselwirkung steht;	13.2. Die Produkte werden so ausgelegt und hergestellt, dass folgende Risiken ausgeschlossen oder so weit wie möglich reduziert werden: d) Risiken im Zusammenhang mit der möglichen negativen Wechselwirkung zwischen Software und der IT-Umgebung, in der sie eingesetzt wird und mit der sie in Wechselwirkung steht;
17.1. Produkte, zu deren Bestandteilen programmierbare Elektroniksysteme, einschließlich Software, gehören, oder Produkte in Form einer Software werden so ausgelegt, dass Wiederholbarkeit, Zuverlässigkeit und Leistung entsprechend ihrer bestimmungsgemäßen Verwendung gewährleistet sind. Für den Fall des Erstauftretens eines Defekts sind geeignete Vorkehrungen zu treffen, um sich daraus ergebende Risiken oder Leistungsbeeinträchtigungen auszuschließen oder sie so weit wie möglich zu verringern.	16.1. Produkte, zu deren Bestandteilen ein programmierbares Elektroniksystem, einschließlich Software, gehört, oder Produkte in Form einer Software werden so ausgelegt, dass Wiederholbarkeit, Zuverlässigkeit und Leistung entsprechend ihrer bestimmungsgemäßen Verwendung gewährleistet sind. Für den Fall des Erstauftretens eines Defekts sind geeignete Vorkehrungen zu treffen, um sich daraus ergebende Risiken oder Leistungsbeeinträchtigungen auszuschließen oder sie so weit wie möglich zu verringern.
17.2. Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.	16.2. Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.
17.3. Bei der Auslegung und Herstellung der in diesem Abschnitt behandelten Software, die zur Verwendung in Verbindung mit mobilen Computerplattformen bestimmt ist, werden die spezifischen Eigenschaften der mobilen Plattform (z. B. Größe und Kontrastverhältnis des Bildschirms) und die externen Faktoren im Zusammenhang mit ihrer Verwendung (sich veränderndes Umfeld hinsichtlich Lichteinfall und Geräuschpegel) berücksichtigt.	16.3. Bei der Auslegung und Herstellung der in diesem Abschnitt behandelten Software, die zur Verwendung in Verbindung mit mobilen Computerplattformen bestimmt ist, werden die spezifischen Eigenschaften der mobilen Plattform (z. B. Größe und Kontrastverhältnis des Bildschirms) und die externen Faktoren im Zusammenhang mit ihrer Verwendung (sich veränderndes Umfeld hinsichtlich Lichteinfall und Geräuschpegel) berücksichtigt.
17.4. Die Hersteller legen Mindestanforderungen bezüglich Hardware, Eigenschaften von IT-Netzen und IT-Sicherheitsmaßnahmen einschließlich des Schutzes vor unbefugtem Zugriff fest, die für den bestimmungsgemäßen Einsatz der Software erforderlich sind, fest	16.4. Die Hersteller legen Mindestanforderungen bezüglich Hardware, Eigenschaften von IT-Netzen und IT-Sicherheitsmaßnahmen einschließlich des Schutzes vor unbefugtem Zugriff, die für den bestimmungsgemäßen Einsatz der Software erforderlich sind, fest.
Die Gebrauchsanweisung enthält alle folgenden Angaben: […] ab) bei Produkten, zu deren Bestandteilen programmierbare Elektroniksysteme, einschließlich Software, gehören, oder Produkte in Form einer Software enthalten, Mindestanforderungen bezüglich Hardware, Eigenschaften von IT-Netzen und IT-Sicherheitsmaßnahmen einschließlich des Schutzes vor unbefugtem Zugriff, die für den bestimmungsgemäßen Einsatz der Software erforderlich sind.	20.4.1. Die Gebrauchsanweisung enthält alle folgenden Angaben: […] ah) bei Produkten, zu deren Bestandteilen programmierbare Elektroniksysteme, einschließlich Software, gehören, oder Produkte in Form einer Software enthalten, Mindestanforderungen bezüglich Hardware, Eigenschaften von IT-Netzen und IT-Sicherheitsmaßnahmen einschließlich des Schutzes vor unbefugtem Zugriff, die für den bestimmungsgemäßen Einsatz der Software erforderlich sind.

b) Technische Spezifikation / Technische Dokumentation

Im Gegensatz zur MDD bzw. IVD trennen die MDR und IVDR die „grundlegenden Anforderungen“ von den Anforderungen an die technische Dokumentation.

Die Anforderungen der MDR und IVDR unterscheiden sich:

Technische Spezifikation (Anhang II)
1.1 Produktbeschreibung und Spezifikation j) eine allgemeine Beschreibung der wichtigsten Funktionselemente des Produkts, z. B. Bestandteile/Komponenten (einschließlich Software, sofern zutreffend), Rezeptur, Zusammensetzung, Funktionsweise und, sofern relevant, qualitative und quantitative Zusammensetzung. Dazu gehören gegebenenfalls gekennzeichnete bildliche Darstellungen (z. B. Diagramme, fotografische Bilder und Zeichnungen), in denen die wichtigsten Bestandteile/Komponenten eindeutig gekennzeichnet sind, einschließlich ausreichender Erläuterungen für das Verständnis der Zeichnungen und Diagramme;	1.1. Produktbeschreibung und Spezifikation g) eine Beschreibung der Komponenten und gegebenenfalls der Wirkstoffe relevanter Komponenten wie Antikörper, Antigene, Nukleinsäureprimer; k) eine Beschreibung der gegebenenfalls mit dem Produkt zu verwendenden Software;
	3.1. Informationen zur Auslegung Informationen, die es ermöglichen, die Auslegungsphasen, die das Produkt durchlaufen hat, zu verstehen, umfassen Folgendes: b) bei Instrumenten eine Beschreibung der wesentlichen Teilsysteme, der Analysetechnik wie Grundsätze für die Handhabung und Kontrollmechanismen sowie der geeigneten Computer-Hardware und Software; c) bei Instrumenten und Software eine Übersicht über das gesamte System; d) bei Software eine Beschreibung der Methodik zur Datenauswertung, d. h. der Algorithmus;
6. Verifizierung und Validierung des Produkts 6.1 Vorklinische und klinische Daten […] b) detaillierte Informationen zum Testaufbau, vollständige Test- oder Studienprotokolle, Methoden der Datenanalyse, zusätzlich zu Datenzusammenfassungen und Testergebnissen, insbesondere hinsichtlich der […] — Verifizierung und Validierung der Software (Beschreibung des Softwaredesigns und des Entwicklungsprozesses sowie Nachweis der Validierung der Software, wie sie im fertigen Produkt verwendet wird. Diese Angaben umfassen normalerweise die zusammengefassten Ergebnisse aller Verifizierungen, Validierungen und Tests, die vor der endgültigen Freigabe sowohl hausintern als auch in einer simulierten oder tatsächlichen Anwenderumgebung durchgeführt wurden. Zudem ist auf alle verschiedenen Hardware-Konfigurationen und gegebenenfalls die in den Informationen des Herstellers genannten Betriebssysteme einzugehen),	6. Überprüfung und Validierung des Produkts 6.4. Software-Verifizierung und Validierung In der Dokumentation wird die Validierung der Software, so wie sie im fertigen Produkt verwendet wird, belegt. Diese Angaben umfassen normalerweise die zusammengefassten Ergebnisse aller Verifizierungen, Validierungen und Tests, die vor der endgültigen Freigabe hausintern und in einer tatsächlichen Verwenderumgebung durchgeführt wurden. Zudem wird auf alle verschiedenen Hardware-Konfigurationen und gegebenenfalls die auf der Kennzeichnung genannten Betriebssysteme eingegangen.

Beide EU-Verordnungen verlangen, dass die Hersteller den Aufbau der Geräte und die Software beschreiben. Die IVDR nennt ganz konkret die Algorithmen. Beide fordern die Tests sowohl „hausintern“ als auch „in einer simulierten oder tatsächlichen Anwenderumgebung“ bzw. in einer „tatsächlichen Verwenderumgebung“. Beiden Verordnungen gemein ist auch die Forderung nach Tests auf „verschiedenen Hardware-Konfigurationen“ und Betriebssystemen.

Die MDR versteht den Begriff „Validierung der Software“ möglicherweise breiter, als die IVDR: Die MDR zählt die Beschreibung des Entwicklungsprozesses und des „Softwaredesigns“ dazu. Offensichtlich sieht sie Validierung ganz im Sinne des FDA Software Validation Guidance Documents auch als Synonym für die konstruktive und analytische Software-Qualitätssicherung.

Darüber, ob diese Unterschiede wirklich beabsichtigt sind, lässt sich nur spekulieren. Die Tatsache, dass nicht einmal die Begriffe abgestimmt sind („Anwenderumgebung“ versus „Verwenderumgebung“), legt nahe, dass die Autoren nicht abgestimmt waren.

Beide EU-Verordnungen differenzieren bei den Anforderungen nicht nach Risiko. Eine Sicherheitsklassifizierung wie die IEC 62304 kennen die Verordnungen nicht.

D.h. die Anforderungen durch die Verordnungen gehen bei Klasse A Software über die Anforderungen der IEC 62304 hinaus.

c) Unique Device Identification UDI

Die Vorgaben der MDR und IVDR für die Vergabe der UDI sind buchstabenidentisch.

d) Klassifizierungsregeln

Die IVDR klassifiziert die Produkte nach den zu bestimmenden Proben bzw. Parametern. Einer „Regel 11“ wie bei der MDR bedarf es daher nicht.

Klassifizierung
3.3. 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.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.
6.3. Regel 11 Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa, es sei denn, diese Entscheidungen haben Auswirkungen, die Folgendes verursachen können: […]

e) Klinische Bewertung und Leistungsbewertung

Die Vorgaben für die klinische Bewertung nach MDR und der Leistungsbewertung nach IVDR unterscheiden sich naturgemäß deutlich. Beispielsweise bedarf es bei einer Leistungsbewertung keiner Diskussion der Äquivalenz (die die Software-Algorithmen beinhaltet). Dafür muss die Leistungsbewertung die Referenzdatenbanken und anderen Datenquellen berücksichtigen.

Klinische Bewertung /Leistungsbewertung
3. Eine klinische Bewertung kann sich nur dann auf klinische Daten zu einem Produkt stützen, wenn die Gleichartigkeit zwischen dem ähnlichen Produkt und dem betreffenden Produkt nachgewiesen werden kann. Zum Nachweis der Gleichartigkeit werden die folgenden technischen, biologischen und klinischen Merkmale herangezogen: — Technisch: Das Produkt ist von ähnlicher Bauart, wird unter ähnlichen Anwendungsbedingungen angewandt, haben ähnliche Spezifikationen und Eigenschaften einschließlich physikalisch-chemischer Eigenschaften wie Energieintensität, Zugfestigkeit, Viskosität, Oberflächenbeschaffenheit, Wellenlänge und Software-Algorithmen, verwendet gegebenenfalls ähnliche Entwicklungsmethoden und hat ähnliche Funktionsgrundsätze und entscheidende Leistungsanforderungen.
	Der Leistungsbewertungsplan enthält generell mindestens Folgendes: — bei als Produkt eingestufter Software Angabe und Spezifizierung der Referenzdatenbanken und anderen Datenquellen, die als Entscheidungsgrundlagen dienen;

f) Fazit und Zusammenfassung

Während die MDR und IVDR identische Vorgaben zu den „grundlegenden Anforderungen“ und der „UDI“ machen, unterscheiden sich die Anforderungen der beiden EU-Verordnungen im Bereich der technischen Dokumentation (insbesondere Entwicklungsprozess, Architektur). Weitere Unterschiede finden sich den unterschiedlichen Zweckbestimmungen geschuldet bei der Klassifizierung und klinischen Bewertung bzw. Leistungsbewertung.

8. Fazit

Mit der IVDR hat die EU-Kommission nun (endlich) Anforderungen auch an Software formuliert. Ein großer Wurf ist damit aber nicht gelungen.

• Viele Formulierungen sind missverständlich und Bezüge unklar.
• Die Anforderungen differenzieren die Risiken nicht ausreichend. Für unkritische Produkte sind sie zu hoch, für kritische zu niedrig oder zumindest zu unkonkret.
• Durch diese handwerklichen Fehler gefährden die Autoren die „Harmonisierbarkeit“ der IEC 62304. Absichtlich?
• Es ist unverständlich, weshalb die Anforderungen bezüglich Software bei Medizinprodukten (MDR) andere sind als bei In-vitro Diagnostika (IVDR).
• Nach 25 Jahren hat man es bei den Medizinprodukten geschafft, den Begriff „Validierung“ eindeutig zu verwenden. Was macht die IVDR? Sie führt genau diese unglückliche Formulierung wieder ein („In der Dokumentation wird die Validierung der Software […] belegt. Diese Angaben umfassen […] Ergebnisse aller Verifizierungen, Validierungen […]“).
• Die Wahl der Anforderungen scheint beliebig. Weshalb stürzen sich die Autoren auf die mobilen Plattformen? Weil sie selbst Besitzer einer solchen geworden sind? Die wirklichen Herausforderungen, bei denen man sich „Guidance“ gewünscht hätte, adressieren die Autoren nicht. Kein Wort zur Bioinformatik. Kein Wort zur künstlichen Intelligenz.

Beim Thema Software hat die EU-Kommission mit der IVDR sicher nicht für mehr Klarheit gesorgt. Vielleicht sollte die Kommission einen Blick in die eigenen Verordnungen wagen: Dort geht es um Anforderungen an die Kompetenz und an die Qualitätssicherung.