Software als Medizinprodukt – Software as Medical Device

Unter Software als Medizinprodukt (Software as Medical Device, SaMD) versteht man (eigenständige) Standalone-Software, die ein Medizinprodukt ist, aber nicht Teil eines solchen.

Sie ist nicht zu verwechseln mit Medical Device Software im Sinne der EU.

Wann müssen Sie als Hersteller Software als Medizinprodukt und wann als Medical Device Software qualifizieren? Das erfahren Sie hier – und können mit diesem Wissen juristische Konsequenzen und unnötige Aufwände vermeiden.

A) Definitionen

1. Software im medizinischen Kontext

Bei Software im Umfeld der Medizinprodukte unterscheidet man:

• Software als Teil eines Medizinprodukts, z. B. als embedded Software eines Medizingeräts
• Software als eigenständiges Medizinprodukt (Standalone-Software)
• Software, die ein Zubehör zu einem Medizinprodukt ist
• (Eigenständige) Software, die kein Medizinprodukt ist.

Abhängig von dieser Klassifizierung müssen Sie als Hersteller unterschiedliche Regularien beachten. Dieser Artikel hilft Ihnen, Ihre Software richtig zu qualifizieren.

2. Definitionen

Es existieren mehrere Definitionen dessen, was unter Software als Medizinprodukt (Software as Medical Device) zu verstehen ist. Eine Definition stammt vom IMDRF, dem International Medical Device Regulators Forum.

Nach Auskunft des deutschen Bundesgesundheitsministerium ist im Leitfaden zur MDR folgende Definition des Begriffs ‚medizinische Software‘ geplant, wie sie von der MDCG erarbeitet wird:

Zusätzlich zu der Definition schreibt die MDCG:

Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.

Quelle: MDCG 2019-11

Damit umfasst Medical Device Software sowohl die sogenannte independent software (also die Standalone-Software) als auch die Steuerungssoftware (oft auch als Funktions-Software bezeichnet).

Diese Definition und das Guidance-Dokument der MDCG haben starke Auswirkungen auf die Klassifizierung von Software und die Anwendbarkeit der Regel 11.

B) Qualifizierung (Klassifizierung) von Software als Medizinprodukt

Die Entscheidung darüber, ob eine Software als Medizinprodukt zählt, bezeichnet man als Qualifizierung, auch wenn umgangssprachlich oft von Klassifizierung gesprochen wird.

Die Zweckbestimmung des Herstellers entscheidet …

Die Frage, wann Software als Medizinprodukt zu qualifizieren ist, stellt sich nur bei Standalone-Software. Die Antwort lautet in Kurzform: Software ist ein Medizinprodukt, wenn der Hersteller sie zur Diagnose, Therapie oder Überwachung von Krankheiten und Verletzungen vorgesehen hat. Punkt.

Exakter und formaler: Software ist genau dann ein Medizinprodukt, wenn die Zweckbestimmung des Herstellers der Definition des Begriffs „Medizinprodukt“ gemäß Artikel 2 (1) der MDR entspricht.

… und nicht primär die Funktionen der Software

Entscheidend bei der Qualifizierung ist also die Zweckbestimmung durch den Hersteller und weniger die Funktion der Software. Bei einer Software, die Vitalparameter erfasst, ließe sich diesbezüglich auf zwei Weisen argumentieren, die zu unterschiedlichen Bewertungen führen:

1. Der Hersteller sagt: Die Erfassung dient nur der Dokumentation.
   Dann ist das Produkt kein Medizinprodukt.
2. Der Hersteller sagt: Der Arzt kann anhand dieser Vitalparameter (und ggf. deren grafischer Darstellung) Trends erkennen und damit das richtige Medikament auswählen.
   Dann ist das identische Produkt ein Medizinprodukt.

Und wenn es keine Zweckbestimmung gibt?

Wenn der Hersteller die Zweckbestimmung nicht eindeutig und widerspruchsfrei formuliert (Handbuch, Verpackung, Webseite, Marketingmaterialien usw.) und sein Produkt nicht als Medizinprodukt klassifiziert, kann es passieren, dass die „liebe Konkurrenz“ eine Abmahnung verschickt. Falls das bei Ihnen der Fall sein sollte, dann melden Sie sich. Wir kennen das.

Falls die Sache vor Gericht landet, wird der Richter wahrscheinlich einen Gutachter beauftragen. Dieser wiederum wird versuchen, aus den Unterlagen (Handbuch etc.) und aus den Funktionen(!) den vom Hersteller vorgesehenen Gebrauch (Zweckbestimmung) abzuleiten. Ob die Schlussfolgerungen des Gutachters in Ihrem Sinne sind, darf bezweifelt werden.

Wer über die Qualifizierung/Klassifizierung von Software als Medizinprodukt entscheidet

Häufig fühlen sich Hersteller und Behörden trotz der Definition des Begriffs unsicher, ob eine Software als Medizinprodukt einzustufen ist. Auch deshalb sind viele Entscheidungshilfen publiziert worden, die Ihnen dieser Artikel im Folgenden vorstellt.

Die Entscheidung, ob eine Software als Medizinprodukt zu qualifizieren ist, trifft der Hersteller selbst. Benannte Stellen können Gutachten erstellen. Damit erlangt der Hersteller aber keine rechtsverbindliche Auskunft. Anfragen beim BfArM werden in der Regel nicht zeitnah beantwortet. Letztlich, das mag zynisch klingen, wird erst ein Richter im Fall einer Klage die Frage nach der Qualifizierung/Klassifizierung final beantworten.

Wenn Sie unsicher sind, ob Ihre Software ein Medizinprodukt ist, dann wenden Sie sich

1. an das Bundesinstitut für Arzneimittel und Medizinprodukte BfArM (Die Reaktionszeit ist aber nicht immer schnell.)
2. an Benannte Stellen. Hier können wir Ihnen Kontakte verschaffen.
3. an das Johner Institut. Wir beantworten ständig solche Fragestellungen und erstellen Gutachten. Schnell und kompetent.

C) Entscheidungshilfen zur Qualifizierung/Klassifizierung von Software as Medical Device

Das Thema „Klassifizierung von Software als Medizinprodukt“ beschäftigt nicht nur Medizinproduktehersteller, sondern auch Behörden, Gremien und Verbände. Diese haben eine Reihe von Dokumenten veröffentlicht, die als Entscheidungshilfen dienen sollen. Wir stellen Ihnen folgende Dokumente vor:

1. COICR Contribution
2. EU: Manual on Borderline and Classification
3. UK Medicines and Healthcare Products Regulatory Agency
4. International Medical Device Regulator Forum IMDRF
5. MEDDEV 2.1.6
6. Schwedische Behörden
7. Asian Harmonization Working Group
8. SwissMedic
9. Britische MHRA
10. FDA
11. Health Canada
12. MDCG (in Europa besonders relevant)
13. Australisches Gesundheitsministerium

1. COICR Contribution

Das „European Coordination Committee of the Radiological, Electromedical and Healthcare IT Industry“ hat ein „Decision Diagram for Qualification of Software as Medical Device“ publiziert.

Vollständiges PDF-Dokument

Über den Wert dieses Dokuments lässt sich streiten. Einerseits steht nichts wirklich Neues drin (und letztlich zählt nur die gesetzliche Definition). Andererseits haben sich hier Menschen viel Arbeit gemacht, um Hersteller und Entwickler zu unterstützen.

2. EU: Manual on Borderline and Classification

Von der EU stammt das Manual (V 1.22 (05-2019)), das anhand von Beispielen versucht, Medizinprodukte von Nicht-Medizinprodukten zu unterscheiden und Hilfe bei der Qualifizierung und Klassifizierung zu geben. Die Beispiele beziehen sich teilweise auch auf Software:

• Picture archiving and communication systems
• Mobile application for processing ECGs
• Mobile application for the communication between patient and caregivers while giving birth
• Mobile medical application for viewing the anatomy of the human body

3. Medicines and Healthcare Products Regulatory Agency

Die britische „Medicines and Healthcare Products Regulatory Agency“ hat ein Dokument mit dem Titel „Borderlines with medical devices“ herausgegeben. Lesen Sie mal im Kapitel 9 den Satz zu den „Telecare Alarm Systems“. Ich wäre an Ihrer Einschätzung interessiert.

4. IMDRF

Zu den sehr relevanten Dokumenten zählt dieses Dokument des International Medical Device Regulator Forums IMDRF. Es definiert folgende Begriffe:

1. Software as a Medical Device (SaMD)
2. Medical Device
3. In Vitro Diagnostic Medical Device
4. SaMD Changes
5. SaMD Manufacturer
6. Intended Use/Intended Purpose

Das Dokument ist mit zehn Seiten angenehm kurz und allemal einen Blick wert. Interessant sind die Referenzen, u. a. die Quellen:

• GHTF/SG1/N55:2008 Definition of the Terms Manufacturer, Authorised Representative,
  Distributor and Importer
• GHTF/SG1/N70:2011 Label and Instructions for Use for Medical Devices
• GHTF/SG1/N71:2012 Definition of Terms Medical Device and In Vitro Diagnostic
  Medical Device
• ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes —
  Maintenance

Das  IMDRF geht nochmals auf die Definition des Begriffs Medizinprodukt (Software as Medical Device) ein und nennt Fälle, unter denen eine Standalone-Software nicht dazu zählt. Umgekehrt gibt das Dokument Hinweise, wann diese Software der Definition entspricht, z. B.

• mitigation of a disease,
• provide information for determining compatibility, detecting, diagnosing, monitoring
• or treating physiological conditions, states of health, illnesses or congenital deformities,
• aid in diagnosis, screening, monitoring, predisposition, prognosis, prediction, determination of physiological status,
• aids for persons with disabilities.

Ob das wirklich bahnbrechende Erkenntnisse zur Qualifizierung von Software als Medizinprodukt sind, lässt sich sicher trefflich diskutieren. Schließlich geht die Hilfestellung nicht entscheidend über die Definition des Begriffs Medizinprodukt hinaus.

5. MEDDEV 2.1.6

Die MEDDEV 2.1/6  hat im Juli 2016 eine aktuelle Version des Guidance on the Qualification and Classification of Stand Alone Software used in Healthcare within the Regulatory Framework of Medical Devices veröffentlicht. Man teilt Software in folgende Kategorien:

1. Software, die kein Medizinprodukt ist, wie Entwicklungswerkzeuge oder Dokumentationssysteme, zu denen auch die KIS zählen (aber nur, solange sie nicht der Diagnose oder Therapie dienen)
2. Software als Bestandteil eines Medizinprodukts, also Gerätesoftware
3. Software, die selbst ein Medizinprodukt ist
4. Software, die ein Zubehör darstellt

Ein im Vergleich zur Version von 2012 überarbeiteter Entscheidungsbaum soll helfen, die richtige Klasse zu bestimmen:

Dieses Dokument dürfte zu den wichtigsten in diesem Kontext zählen. Richter und Gutachter (auch wir) stützen uns fast immer darauf.

Diese EU-Leitlinie gibt auch Hilfestellung bei der Klassifizierung von IVD Software.

6. Schwedische Behörden

Von den schwedischen Behörden gab es den Leitfaden „Medical Information Systems – guidance for qualification and classification of standalone software with a medical purpose“. Dieser Link ist seit Februar 2020 nicht mehr aufrufbar.

7. Asian Harmonization Working Group — Software Qualification and Classification

Das Dokument der Asian Harmonization Working Group wiederholt die Definitionen im Kontext „Software als Medizinprodukt“ wie Standalone-Software, „Mobile Medical Application“ und „Health Software“. Es unterscheidet drei Typen:

1. Software, die Teil eines Medizinprodukts ist (oft als embedded Software bezeichnet)
2. (Standalone-) Software, die ein Zubehör für ein Medizinprodukt ist, z. B. zum Weiterleiten von Daten
3. Standalone-Software, die selbst ein Medizinprodukt ist (Software as a Medical Device SaMD) und auf Datenträger, per Download oder webbasiert zur Verfügung gestellt wird

Weiterhin stellt das Dokument bekannte Überlegungen zur Klassifizierung von Software als Medizinprodukt vor und diskutiert dabei im Wesentlichen die bereits oben genannten Quellen:

• Die Veröffentlichung des IMDRF (s. o.)
• Die australische Therapeutic Goods Association (TGA) referenziert selbst wieder europäische und US-amerikanische Veröffentlichungen. Sie klassifiziert Dokumentations-Software nicht als Medizinprodukt, ebenso wenig Software, die nur einfache Berechnungen ausführt, die nicht auf patientenspezifischen Daten basieren. Falls die Software ein weiteres Medizinprodukt kontrolliert oder beeinflusst, fällt es in die gleiche Klasse wie das Medizinprodukt.
• Die Chinese Food and Drug Administration CFDA hat eine genaue Richtlinie zur Registrierung von Software als Medizinprodukt veröffentlicht, die wiederum die Sicherheitsklassifizierung gemäß IEC 62304 verwendet.
• Von den in Europa veröffentlichten Dokumenten wird die MEDDEV 2.1/6 (s.o.) genannt, ebenso tabellarisch einige Beispiele für Software, die als Medizinprodukt oder als Nicht-Medizinprodukt zu klassifizieren wären. Auch werden die Klassifizierungsregeln des Anhangs IX der MDD zitiert.
• Kurz bespricht das Dokument die Vorgaben von Health Canada und erwähnt dabei v. a. ein FAQ-Dokument, das Beispiele und Regeln zur Klassifizierung von Software als Medizinprodukt gibt. Eine Tabelle nennt konkrete Beispiele.
• In den Vorgaben des japanischen MHLW (Ministry of Health, Labor and Welfare) steht, dass Standalone-Software ein Medizinprodukt sein kann und dass weitere Empfehlungen gerade erarbeitet werden.
• Eine Übersicht über die Vorgaben der FDA (s. o.) schließt den Reigen der untersuchten Rechtsbereiche ab.

In der Zusammenfassung stellt das Dokument Gemeinsamkeiten und Unterschiede u. a. tabellarisch zusammen. Dabei kommt auch Software zur Sprache, die der Datenkommunikation dient. Diese Software ist in Europa nicht als Medizinprodukt zu klassifizieren, in den meisten anderen Rechtsbereichen schon.

8. SwissMedic

Auch die SwissMedic hat sich im AW-Merkblatt Eigenständige Medizinprodukte-Software zu dem Thema geäußert. Sie fasst dabei viele der o. g. Quellen zusammen, ohne neue Erkenntnisse zu liefern. Interessant ist die klare Aussage, dass für „betriebsintern“ (z. B. innerhalb von  Krankenhäusern) hergestellte Software die gleichen Voraussetzungen erfüllt sein müssen. Die Schweizer Behörde schreibt sogar:

„Betriebsintern hergestellte Software wird per Definition zwar nicht in Verkehr gebracht, die Anwendung durch eine Fachperson wird jedoch dem erstmaligen Inverkehrbringen gleichgesetzt.“

9. Die britische MHRA

Die britische Medical & Healthcare products Regulatory Agency (MHRA) hat im September 2022 ein Dokument veröffentlicht, mit dem sie erklären will, wann Software ein Medizinprodukt ist und wann nicht.

Die Regeln sind im Wesentlichen dieselben wie in der Leitlinie MDCG 2019-11.

Die MHRA hat sich dabei viel Mühe gemacht, die Vorgaben und Regeln auch visuell ansprechend und leicht verständlich zu formulieren. Leider wirft auch sie Zweckbestimmung (z. B. „Prevention of Disease“), Funktionen („Stores or transmits medical data“) und technische Charakterisierungen (z. B. „Database without internal language“) durcheinander, was der Klarheit schadet.

10. FDA zur Qualifizierung und Klassifizierung von Software als Medizinprodukt

a) Food, Drug, and Cosmetic Act (FD&C)

Der amerikanische Food, Drug and Cosmetic Act, kurz FD&C, hat im Sommer 2017 die Definition des Begriffs ‚Medizinprodukt‘ speziell für Software überarbeitet. Allerdings ist diese Beschreibung so kryptisch geworden, dass die FDA im Dezember 2017 ein Guidance-Dokument veröffentlichte, das ihre Interpretation des Gesetzes darlegt. Diese Darlegung bezieht sich zwar nur auf Decision-Support-Systeme, ist aber auf andere Standalone-Software sehr gut übertragbar.

Im September 2019 hat die FDA das Guidance-Dokument Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act veröffentlicht. Darin legt die Behörde ihre Sicht der Dinge nochmals ausführlich dar, nennt Beispiele und verweist auf weitere (z. T. im Folgenden genannte) Dokumente.

b) General Wellness: Policy for Low Risk Devices

Bereits Ende November 2016 wurde der Food, Drug & Cosmetic Act überarbeitet. Er definiert Software „for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition“ nicht(!) mehr als Medizinprodukt.

Die FDA bestätigt in ihrem Guidance-Dokument General Wellness: Policy for Low Risk Devices, dass sie weder untersuchen wolle, ob solche „low risk general wellness products“ Medizinprodukte seien, noch, ob solche Produkte, die als Medizinprodukt klassifiziert werden, den regulatorischen Anforderungen genügen.

Voraussetzung dafür sind aber:

1. Die Produkte dienen ausschließlich dem allgemeinen Wohlbefinden („Wellness“) wie in diesem Dokument definiert.
2. Die Produkte stellen ein niedriges Risiko dar.

Die Hersteller dürfen keinen Bezug zu Krankheiten herstellen, die mit den Produkten diagnostiziert oder behandelt werden sollen. Vielmehr geht es beispielsweise um

• Gewichtsmanagement (aber nicht Behandlung von Fettleibigkeit!),
• körperliche Fitness,
• Stress-Management,
• Schlaf.

Allerdings gestattet die FDA auch Produkte mit Bezug zu bestimmten Krankheiten in dieser Kategorie, falls sie ggf. dabei helfen,

• Risiken bestimmter chronischer Erkrankungen zu minimieren,
• mit bestimmten chronischen Erkrankungen besser zu leben.

Das Guidance-Dokument nennt Beispiele und liefert einen kleinen Entscheidungsbaum.

Fazit: Mit diesem Dokument schafft die FDA Klarheit, wann Produkte – auch Software – von der Überwachung durch die FDA ausgeschlossen sind. So etwas wünscht man sich in Europa auch. Die Behörde nimmt zudem viel mehr Produkte von der Überwachung aus als die europäische Behörden und Regulatoren.

c) Policy for Device Software Functions and Mobile Medical Applications

Bereits die aus dem Jahr 2016 stammende Guidance zu Mobile Medical Apps grenzte Apps ab, die

• kein Medizinprodukt sind,
• ein Medizinprodukt sind, aber von der FDA nicht überprüft werden,
• ein Medizinprodukt sind, das den FDA-Überprüfungen unterliegt.

Mit dem Update im Jahr 2019 hat die FDA den Scope auch auf sonstige Software ausgedehnt und spricht jetzt häufig von „Software Functions“. Mobile Apps sind nur noch ein Typ von Software, die über solche Funktionen verfügt.

Das heißt, dass Sie das Dokument auch dann zurate ziehen sollten, wenn Sie bei Software, die keine Mobile Medical App ist, entscheiden müssen, ob sie ein Medizinprodukt ist.

Mehr dazu lesen Sie im Artikel über Mobile Medical Apps.

d) FDASIA Report

Die FDA ist Mitherausgeberin des FDASIA Reports. FDASIA steht für §Food and Drug Adminstration Safety and Innovation Act§, der von der FDA verlangt, einen Bericht zu erstellen,

„that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication.“

Die FDA unterscheidet (wie im Guidance-Dokument zu den Mobile Medical Apps):

1. Nicht-Medizinprodukte
2. Medizinprodukte, bei denen die FDA die Einhaltung der gesetzlichen Forderungen (z. B. Zulassungsverfahren, Quality Systems Regulations) einfordert
3. Medizinprodukte, bei denen sie es nicht tut

Diese Dreiteilung ist überraschend. Gesetze müssen also nicht immer eingehalten werden? Die FDA begründet diese Differenzierung mit einem „risk-based approach“:

„In applying a risk-based approach, FDA does not intend to focus its regulatory oversight on these products/functionalities, even if they meet the statutory definition of a medical device.“

Sie nennt dann auch konkrete Beispiele, bei denen sie diese Ausnahmen für gerechtfertigt hält:

1. Evidence-based clinician order sets tailored for a  particular condition, disease, or clinician  preference;
2. Drug-drug interaction and drug-allergy  contraindication alerts to avert adverse drug  events;
3. Most drug dosing calculations;
4. Drug formulary guidelines;
5. Reminders for preventative care (e.g.  mammography, colonoscopy, immunizations,  etc.);
6. Facilitation of access to treatment guidelines and  other reference material that can provide  information relevant to particular patients;
7. Calculation of prediction rules and severity  of illness assessments (e.g., APACHE score, AHRQ Pneumonia Severity Index, Charlson Index);
8. Duplicate testing alerts;
9. Suggestions for possible diagnoses based on patient-specific information retrieved from a  patient’s EHR.

Es wird nicht ganz klar, auf welcher statistischen Analyse die Annahmen beruhen, dass die o. g. Produktklassen wenige Risiken bergen. Solche Clinical-Decision-Support-Systeme sind oft besonders tückisch, weil sich die Risiken nicht so offenbaren wie bei klassischen Medizingeräten wie Beatmungsgeräten.

Ein neues Guidance-Dokument nennt konkrete Beispiele, wann Software nicht mehr als Medizinprodukt zu klassifizieren ist:

• Software zur administrativen Unterstützung
• Laborinformationssysteme (solange es nur um eine administrative Unterstützung, um Speicherung, Transport und Umwandlung von Labordaten geht)
• Software, die einen gesunden Lebensstil unterstützen will, z. B. eine App, die Bewegung aufzeichnet und darstellt, oder eine App, die den Benutzer warnt, wenn er zu viel oder ungesund isst. Auch Tagebücher und soziale Spiele zählen zu den Beispielen.
• Elektronische Patientenakten, allerdings nur, wenn drei Bedingungen erfüllt sind:
  • Sie werden durch oder unter der Aufsicht von Healthcare Professionals gepflegt.
  • Sie unterliegen nicht dem Health IT Certification Program.
  • Sie dienen nicht der Analyse von Aufzeichnungen einschließlich Bildern mit dem Zweck einer Diagnose, Behandlung, Linderung oder Überwachung.
• Software, die nur der Weiterleitung, Speicherung, Formatumwandlung und Anzeige von Labordaten und anderen Gerätedaten dient, solange keine Analyse dieser Daten erfolgt. Damit sind die Medical Device Data Systems keine Medizinprodukte mehr. Auch PACS zählen nicht mehr zu den Medizinprodukten.

Entsprechend muss die FDA die oben genannten Guidance-Dokumente überarbeiten.

e) Digital Health Policy Navigator

De FDA gibt Unterstützung bei der Qualifizierung und Klassifizierung von „Device Software Functions“. Sie hat dazu einen Digital Health Policy Navigator entwickelt, der in sieben Schritten bei der Entscheidungsfindung hilft.

11. Health Canada

Health Canada hat den Entwurf des „Guidance Document – Software as a Medical Device (SaMD)“ herausgegeben. Es stützt sich im Wesentlichen auf das oben erwähnte „Framework“ des IMDRF und übernimmt dessen Definitionen. Es ergänzt dessen Gedanken durch Beispiele.

a) Medizinischer Zweck

So nennt Health Canada Beispiele für eine medizinische Zweckbestimmung:

• Akquirieren, Verarbeiten oder Analysieren von medizinischen Bildern
• Akquirieren, Verarbeiten oder Analysieren von Informationen, die von einem IVD stammen
• Akquirieren, Verarbeiten oder Analysieren von Informationen, Messungen oder Signalen, die von einem Monitoring- oder bildgebenden Gerät stammen
• Unterstützung oder Bereitstellen von Empfehlungen für Patienten oder medizinisches Personal zur Vorbeugung, Diagnose, Behandlung, Linderung von Krankheiten oder Verletzungen

Allerdings qualifiziert Health Canada nicht alle entscheidungsunterstützenden Systeme als Medizinprodukt.

b) Beispiele für Software, die kein Medizinprodukt ist

Health Canada hilft auch mit Beispielen für Software, die die Behörde nicht zu den Medizinprodukten zählt:

• Reine Kommunikationssysteme wie MDDS, Telefonie etc.
• Software mit rein administrativen Zwecken einschließlich Workflow, Patientenverwaltung, Scheduling
• Software, die zu einem gesünderen Lebensstil beiträgt, wie Wellness Apps
• Elektronische Patientenakten
• Software, die Zugang zu Literaturdaten verschafft
• Software, die vor Medikamentenwechselwirkungen warnt
• Software, die keine unmittelbaren Handlungen auslöst
• Software für einfache medizinische Berechnungen

c) Risikoklassifizierung

Bei der Risikoklassifizierung lehnt sich Health Canada ebenfalls an das IMDRF Dokument an, erlaubt aber an manchen Stellen eine niedrigere Klassifizierung.

12. MDCG

a) Übersicht

Das Dokument MDCG 2019-11 regelt die Qualifizierung und Klassifizierung von Medical Device Software unter der MDR. Es löst damit die oben erwähnte MEDDEV 2.1/6 ab. Zentral für viele Hersteller ist das Klassifizierungsschema:

Besonders relevant ist die letzte Fallunterscheidung „Is the Software a Medical Device Software according to the definition of this Guidance?“

Zur Erinnerung:

Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.

MDCG 2019-11

Die MDCG weist darauf hin, dass es für die Klassifizierung als MDSW irrelevant ist,

• wo die Software läuft (in der Cloud, auf SmartPhone, auf dem Server),
• wer die Software nutzt (Laien, Healthcare Professionals),
• ob die Software ein Medizinprodukt ansteuert oder nicht und
• ob die Software eigenständig läuft oder Teil eines Medizinprodukts ist.

b) Beispiele

Die MDCG nennt Beispiele für solche Medical Device Software (MDSW):

• Standalone-Software, die der Diagnose oder Behandlung dient einschließlich Software zur Bewertung des Risikos einer Trisomie 21 eines Kindes basierend auf den Serummarkern der Mutter
• Software, die aus Ultraschallbildern und Laborparametern eines Patienten das Risiko von Prostatakrebs berechnet
• Software eines Massenspektrometers, die aus den Daten Mikroorganismen und deren Antibiotika-Resistenz feststellt
• App, die Alarme an den Patienten oder Arzt schickt, wenn sie aus unregelmäßigen Herzschlägen eine Arrythmie erkennt
• Software, die Glukosewerte misst, anhand derer die Insulindosis bestimmt und damit eine Insulinpumpe ansteuert (ggf. sogar als Closed-Loop-System)
• Cloud-basierte Software, die einen Point-of-Care-Test durchführt

c) Sonderfall: Software nur zur Steuerung von Hardware

Wenn eine Software ausschließlich zur Steuerung der Hardware eines Medizinprodukt dient und keine eigenen medizinischen Zwecke verfolgt, ist sie nur als Zubehör dieses Medizinprodukts zu betrachten. Eine zusätzliche Klassifizierung gemäß Regel 11 kommt dann nicht in Betracht.

d) Kritik am MDCG-Dokument

Nur wenige Tage nach Veröffentlichung kam Kritik auf. Bei LinkedIn hat Professor Antonio Bartolozzi eine Präsentation publiziert:

Das Johner Institut schätzt diese Kritik wie folgt ein:

• Neue und nicht abgestimmte Definition
  Es ist zutreffend, dass die neue Definition des Begriffs Medical Device Software (MDSW) von bestehenden Definitionen abweicht. Das kann Verwirrung stiften. Gleichzeitig stellt diese eigene Definition das eigentliche Konzept dar, das u.a. dazu führen kann und soll(!), dass Software, die Teil eines physischen Medizinprodukts ist, das ganze Medizinprodukt höher klassifiziert.
• Neues Konzept
  Weitere Kritikpunkte in der Präsentation scheinen dadurch bedingt zu sein, dass der Autor sich mit diesem Konzept nicht abfinden will oder es nicht versteht. Eine bewusste Abgrenzung und Gegenüberstellung der Konzepte hätte dem MDCG-Dokument aber gut getan.
• Verbindlichkeit der MDCG-Dokumente
  Die Rechtsverbindlichkeit der MDCG-Dokumente zu hinterfragen, ist legitim. Hier werden unter Umgehung parlamentarischer Prozesse oder anderer Formen der Konsensbildung (wie bei der Normung) Regeln festgelegt, die de facto als verbindlich interpretiert werden. Sogar die EuGH-Richter haben sich auf solche Dokumente gestützt.
• Beispiele
  Weiter kritisiert Prof. Bartolozzi heftig die Beispiele. Natürlich werden Krankenhaus-Informationssysteme dazu genutzt, um Informationen für die Diagnose und Behandlung zu erhalten. Das steckt aber nicht in deren Zweckbestimmung. Dass diese Systeme folglich falsch klassifiziert sind, ist zutreffend. Das zu regeln war aber nicht der Auftrag der MDCG.
  Ebenso kann man zustimmen, dass ein PDMS ein Medizinprodukt ist. Hier windet sich die MDCG mit dem Hinweis auf Module etwas unglücklich aus der Sache.
• Inkonsistenzen
  In der Tat sollte die Klassifizierung von Medizinprodukten mit identischer Zweckbestimmung nicht davon abhängen, ob es Software- oder Hardware-Produkte sind.

Fazit: Die an manchen Stellen mit zahllosen Ausrufezeichen etwas unbeherrscht wirkende Kritik ist nicht ganz von der Hand zu weisen. Die Regel 11 ist in der jetzigen Form ungeeignet. Das MDCG-Dokument heilt diesen Missstand nur bedingt. Das liegt auch daran, dass es

• neue Definitionen und Konzepte einführt, ohne diese ausreichend zu erläutern und abzugrenzen,
• bestehende Konzepte (z. B. IMDRF) verbiegt,
• so formuliert, dass es nicht jeden Usability-Test bestehen würde, und
• an manchen Stellen zumindest etwas willkürlich bzw. als im Widerspruch mit vorhandenen Regeln stehend wirkt.

Die von Herrn Bartolozzi vorgeschlagene Klassifizierung hält das Johner Institut nicht für die Lösung. Demnach würden noch mehr Produkte in die Klasse III fallen, als dies die MDCG vorschlägt.

Er selbst argumentiert, dass die Klassifizierung risikobasiert erfolgen sollte, zieht sich dann aber auf die Regel 11 zurück, die nur die Schweregrade möglicher Schäden betrachtet.

13. Australien

Im Dokument Exemption for Certain Clinical Decision Support Software Guidance on the exemption criteria beschreibt die australische TGA, unter welchen Umständen ein Clinical Decision Support System nicht der Regulierung unterliegt.

Das ist der Fall, wenn drei Bedingungen erfüllt sind:

1. Die Software dient ausschließlich dazu, „Health Professionals“ Empfehlungen zur Diagnose, Verhütung, Heilung und Linderung von Krankheiten und Verletzungen zu geben.
2. Sie analysiert oder verarbeitet nicht direkt medizinische Bilddaten oder Biosignale anderer Medizinprodukte (einschließlich IVD).
3. Sie soll die Beurteilung durch Health Professionals bezüglich Diagnose oder Therapie nicht ersetzen.

Es gibt sehr viele Produkte, die von diesen Erleichterungen profitieren.

D) Beispiele für Software als Medizinprodukt

1. Webseite als Medizinprodukt

Fragestellung

Heise Online berichtete über ein Start-up, dessen Geschäftsidee darin bestand, Diagnosen von Hautkrankheiten zu erstellen. Die Webseite der Firma führte durch einen Fragebogen und erlaubte es, Fotos der eigenen Haut hochzuladen. Innerhalb von 48 Stunden erhielt man eine Antwort − das alles für nur 29 EUR. Die Webseite ist inzwischen offline.

Es stellt sich schnell die Frage, ob eine/diese Webseite ein Medizinprodukt ist. Webseiten können generell Medizinprodukte sein. Und wie sieht es mit der konkreten Webseite aus? Fällt sie ebenfalls unter die Definition des Begriffs Medizinprodukt?

Bewertung

Die 2007/47 hat klargestellt, dass auch Standalone-Software unter die Definition Medizinprodukt fällt, wenn sie der Diagnose, Therapie und Überwachung von Krankheiten und Verletzungen dienen soll, um es etwas verkürzt wieder zu geben. Der Gedanke liegt nahe, dass die besprochene Webseite der Diagnose von Krankheiten dient, denn das Angebot ist die Diagnose von Hautkrankheiten.

Für die Klassifizierung (nicht nur von Webseiten) als Medizinprodukt ist die Frage, ob etwas passieren kann, nicht entscheidend.

2. Webservice als Medizinprodukt

a) Beispiel

Die Firma Promedas bot einen Webdienst an, der eine API für medizinische Diagnosen bietet.

Auf der Webseite des Herstellers hieß es:

Promedas provides a clinical expertise system to medical professionals. The Promedas API can be integrated into existing medical systems that contain a patient file database. Using this data, Promedus can provide a differential diagnosis based on the data contained in a patient’s file. The API is currently in a developer beta. To access the API, contact Promedas.

b) Fragestellungen

Damit ergeben sich gleich Fragen wie die folgenden:

1. Ist dieser Webservice selbst schon ein Medizinprodukt?
2. Wenn man diesen Service in eigene Software integriert, wie muss man ihn dann normgerecht behandeln? Als SOUP?
3. Wenn dieser Webservice eine einfache GUI hat, kann er theoretisch weltweit aufgerufen und genutzt werden. Muss er dann automatisch für alle internationalen gesetzlichen Anforderungen ausgelegt werden? Selbst wenn es einen Intended Use gäbe, dass der Dienst nur in der EU angewendet werden darf, dann würde im Rahmen der Marktbeobachtung sofort ersichtlich, dass er auch in den USA aufgerufen wird. Müsste er damit auch die FDA-Anforderungen erfüllen?

c) Bewertung

Frage 1: Bis vor kurzem hätte die Antwort lauten müssen „nein“. Der Webservice ist kein Medizinprodukt, weil er selbst nicht der Diagnose oder Behandlung von Patienten dient, sondern zur Integration in ein System vorgesehen ist, dessen Zweckbestimmung in der Diagnose oder Behandlung liegt.

Nach dem EuGH-Urteil (siehe unten) muss diese Einschätzung widerrufen werden. Demnach dürfen „Module“ eines Produkts als Medizinprodukt klassifiziert werden, selbst wenn das Produkt, in das die Komponenten integriert sind, kein Medizinprodukt ist.

Frage 2: Es ist durchaus denkbar, einen Webservice als SOUP zu deklarieren und als Komponente, deren Entwicklung nicht den Anforderungen der IEC 62304 genügt, in ein Medizinprodukt zu integrieren. Im Rahmen des Risikomanagements wären dieses Vorgehen und diese Komponente natürlich zu bewerten.

Frage 3: Über einen Ausschluss in der Zweckbestimmung wäre man bereits aus dem Schneider. Wenn eine Behörde Maßnahmen androht, weil Kliniken oder Ärzte offensichtlich diese Vorgabe ignorieren, könnte man das über eine IP-Filterung einigermaßen gut lösen. Eine Behörde in Europa hat aber keine Handhabe in den USA und umgekehrt. Daher würde sie nie in einem anderen Rechtsbereich aktiv werden.

3. Dokumentenmanagementsysteme

a) Fragestellung

Im Rahmen des kostenlosen Micro-Consultings erreichte uns die Frage, ob Dokumentenmanagementsysteme (DMS) Medizinprodukte seien. Man argumentierte, dass durch Fehler in einem DMS Patienten zu Schaden kommen könnten. Andererseits würden aber immer Ärzte die letzte Entscheidung treffen.

b) Bewertung

Beide Überlegungen sind wichtig, aber für die Klassifizierung als Medizinprodukt nicht relevant:

Software fügt nie direkt Schaden zu. Immer sind es Menschen oder Hardware, die letztlich den Patienten verletzen oder schädigen.

Relevant ist hingegen die Aussage des Herstellers, wofür seine Kunden das Produkt nutzen können und sollen. Wenn der Hersteller sagt, dass das System nur der Dokumentation dient, ist es kein Medizinprodukt. Wenn der Hersteller hingegen sagt, dass damit z.B. Röntgenbilder für die Verlaufskontrolle gespeichert werden sollen, dient das System der Therapie und ist damit definitionsgemäß ein Medizinprodukt.

Über die Formulierung dieser Zweckbestimmung kann der Hersteller sein Produkt zum Medizinprodukt machen oder eben nicht. Dabei ist die Zweckbestimmung nicht nur ein Dokument. Vielmehr dokumentiert der Hersteller dies auf die vielfältigste Weise:

• In der Gebrauchsanweisung
• In der Online-Hilfe des Produkts
• Auf seiner Webseite
• In Marketingmaterialien wie Flyern
• Auf Messen
• Sogar in Gesprächen

Daher empfiehlt das Johner Institut den DMS-Herstellern, sich eindeutig zu artikulieren. Das kann auch explizite Ausschlüsse von Funktionalitäten oder Anwendungsszenarien beinhalten.

Haben Sie Fragen zur Klassifizierung Ihres Produkts? Dann nutzen Sie unser kostenloses Micro-Consulting.

4. Krankenhaus-Informationssystem (KIS) als Medizinprodukt

a) Fragestellung

Die Aufgabe klinischer Informationssysteme (KIS) besteht offensichtlich darin, die Anwender bei der Diagnose, Überwachung und Behandlung von Patienten zu unterstützen. Dass diese Systeme auch gelegentlich Patienten (indirekt) gefährden, ist ebenfalls nicht unbekannt. Das kann der Fall sein, wenn sie

• Patientendaten vertauschen,
• Daten verlieren,
• sehr langsam auf Benutzereingaben reagieren (z.B. bei einem Malware-Befall),
• überhaupt nicht mehr reagieren, nicht mehr starten, komplett ausfallen oder
• Informationen nicht an andere Systeme weiterleiten.

b) Bewertung

Entscheidend für die Frage, ob diese Software als Medizinprodukt zu klassifizieren ist, ist auch hier nicht die die Gefährdung, sondern nur die Übereinstimmung der Zweckbestimmung mit der Definition des Begriffs Medizinprodukt.

• Ein System, das nur zur Dokumentation oder Abrechnung vorgesehen ist, fällt nicht darunter.
• Ein  System, das aus eingegebenen Werten Diagnose- oder Therapieempfehlungen ableitet, das Warnungen beispielsweise bei Medikamentenwechselwirkungen gibt, schon.

c) Konsequenzen für die Betreiber

Da auf Dauer kein KIS-Hersteller überleben wird, dessen Systeme nichts anderes können, als eingegebene Daten wieder anzuzeigen, werden mittelfristig alle KIS zum Medizinprodukt. Das will nur keiner hören, besonders nicht die Betreiber, nämlich die Krankenhäuser.

Der Grund ist offensichtlich: Sobald ein KIS als Medizinprodukt klassifiziert ist, unterliegt es der Medizinprodukte-Betreiberverordnung. Und diese verlangt u. a.:

• Personen, welche das System anwenden, betreiben und instand halten, müssen geschult sein. Das gilt es zu dokumentieren.
• Das System muss regelmäßig überprüft werden, spätestens alle zwei Jahre.
• Nach jeder Instandhaltungsmaßnahme (Software-Update) müssen alle sicherheitsrelevanten Funktionen und Konstruktionsmerkmale geprüft werden.

Doch wie sollen Krankenhäuser dies bewerkstelligen? Wie sollen sie vollständig prüfen, dass nach einem Software-Update ein KIS mit Diagnosefunktionalität noch funktioniert? Dass es mit dem RIS, das im gleichen Netzwerksegment hängt, noch fehlerfrei zusammenarbeitet? Dass es keine Rückwirkungen auf Ultraschallgeräte gibt, die ebenfalls ans Netzwerk angeschlossen sind?

Die einzige Möglichkeit, diese nahezu unendlichen Kombinationen möglicher Fehlerursachen anzugehen, besteht darin, ein Risikomanagement zu betreiben, mit dem sich die Prüfschritte priorisieren lassen.

Einige Firmen klassifizieren ihre Systeme als Medizinprodukt, wie z. B. GE Healthcare sein Informationssystem Centricity, das die CE-Kennzeichnung (gemäß MDD, 93/42/EC) erhielt. Hierzu die entsprechende Pressemeldung von GE.

5. Software als IVD

Software kann nicht nur als Medizinprodukt (gemäß MDD/MDR), sondern auch als IVD (gemäß IVDD/IVDR) klassifiziert werden.

6. ChatGPT als Medizinprodukt

Dass ChatGPT auch auf medizinische Fragen Antworten gibt, wissen oder ahnen Sie. Eine Kanzlei kommt deshalb zu der Schlussfolgerung:

„Unserer Rechtsauffassung nach fällt diese Software in Deutschland und in Europa unter die Regulation als Medizinprodukt“

Apotheke Adhoc

Auch die E-HEALTH-COM berichtet, dass eine „auf digitale Medizinprodukte spezialisierte Kanzlei“ beim BfArM „die regulatorische Einordnung der KI-basierten Software ChatGPT als Medizinprodukt gefordert“ hat.

Als Grund wird die Erkenntnis genannt, dass „ChatGPT aufgrund seiner diagnostischen und therapeutischen Nutzungsmöglichkeiten in den Anwendungsbereich der Medical Device Regulation (MDR) fällt“.

Das Johner Institut stimmt zu, dass ChatGPT diagnostisch und therapeutisch genutzt werden kann. Hingegen kann es die Schlussfolgerung nicht nachvollziehen, dass ChatGPT bereits durch die Möglichkeit, so genutzt zu werden, zum Medizinprodukt wird.

Entscheidend ist die Zweckbestimmung des Herstellers. Es ist davon auszugehen, dass OpenAI seine Produkte nicht dazu vorsieht, diagnostisch oder therapeutisch genutzt zu werden. In seinen Terms of use schreibt die Firma:

„You must not use any Output relating to a person for any purpose that could have a legal or material impact on that person, such as […] medical, or other important decisions about them.”

Wenn hingegen ein Medizinprodukt ChatGPT nutzt, dann muss das ganze Produkt die regulatorischen Anforderungen erfüllen. Zwar ließe sich ChatGPT als SOUP deklarieren; aber Spezifikation und Verifikation dieser Komponente dürften ebenso schwierig werden wie der Nachweis eines positiven Nutzen-Risiko-Verhältnisses.

Man darf gespannt sein, ob und wie das BfArM reagiert. Die Durchsetzung der gesetzlichen Anforderungen liegt bei den Ländern …

Zertifizieren Sie Ihre Software mit Leichtigkeit als Medizinprodukt

Entdecken Sie jetzt, wie Sie Ihre Software als Medizinprodukt zertifizieren lassen können. Erfahren Sie alles über die IEC 62304 Norm und lernen Sie, wie Sie die Anforderungen einfach und praxisorientiert umsetzen können. Mit über 25 Videos und einem kompletten Set einer IEC 62304-konformen Software-Akte unterstützen wir Sie dabei, Ihre Software erfolgreich zu zertifizieren.

Mehr erfahren

7. Weitere Beispiele

Viele weitere Beispiele enthält der Anhang I des MDCG Guidance Documents:

• Hospital Information Systems
• Decision Support Software
• Electronic Patient Record Systems
• Clinical Information Systems – CIS/Patient Data Management Systems – PDMS
• Pre-hospital Electrocardiograph (ECG) System
• Picture Archive Communication System (PACS)
• Telemedicine systems
• Telesurgery
• Web systems for monitoring of data
• Laboratory Information Systems (LIS) and Work Area Managers (WAM)
• IVD: Expert system
• IVD: Interpretation of raw data
• IVD: Home care monitoring, wired or mobile
• IVD: Image Management System (IMS)

E) Sonderfall: Komponenten als Medizinprodukt

1. MEDDEV 2.1/6: Nur „Medizinische Module“ müssen MDD erfüllen

Die EU-Kommission hat im Juli 2016 die Leitlinie MEDDEV 2.1/6 (siehe unten) mit dem länglichen Titel „Guidelines on the Qualification and Classification of Stand Alone Software used in the Healthcare within the Regulatory Framework of Medical Devices“ in einer zweiten Version veröffentlicht.

Dieses Dokument stellt fest, dass eine Software aus Modulen bestehen kann. Nur die Module müssten den Anforderungen der Medizinprodukterichtlinie genügen, die eine entsprechende medizinische Zweckbestimmung verfolgen. So steht geschrieben:

„Some stand alone software may break down into a significant number of applications for the user where each of these applications is correlated with a module. Some of these modules have a medical purpose, some not. The modules which are subject to the medical device Directives (Figures 1 and 2) must comply with the requirements of the medical device Directives and must carry the CE marking. The non-medical device modules are not subject to the requirements for medical devices.“

Die MDCG verfolgt diesen Ansatz weiter. Sie schreibt:

Computer programmes used in healthcare can have applications which consist of both medical device and non-medical device modules.
The modules which are subject to the Medical Devices Regulations must comply with the requirements of the medical device regulations and must carry the CE marking. The non-medical device modules are not subject to the requirements for medical devices. It is the obligation of the manufacturer to identify the boundaries and the interfaces of the different modules.

MDCG 2019-11

Ein Beispiel für solch eine Software könnte ein Krankenhaus-Informationssystem darstellen, das aus Nichtmedizinprodukte-Modulen (Abrechnung, Stammdatenverwaltung usw.) und Medizinprodukte-Modulen (z. B. Arzneimittelprüfung, radiologische Befundung) besteht.

In den meisten Fällen wird man die Standalone-Software als Ganzes als Medizinprodukt zertifizieren und nicht deren einzelne Komponenten. Beispielsweise würde man bei einer Software zur Arzneimittelsicherheit nicht anstreben, einzelne Module zu zertifizieren.

2. Bestätigung durch das EuGH

Ein EuGH-Urteil vom Dezember 2017 bestätigt die Möglichkeit, Software-Module mit/ohne Medizinprodukteigenschaft abzugrenzen. Der Europäische Gerichtshof schreibt im Absatz 36 klar:

„Im Fall einer medizinischen Software, die gleichzeitig Module umfasst, die der Definition von ‚Medizinprodukt‘ entsprechen, und andere, die ihr nicht entsprechen und kein Zubehör im Sinne von Art. 1 Abs. 2 Buchst. b der Richtlinie 93/42 sind, fallen nur die erstgenannten Module in den Anwendungsbereich dieser Richtlinie und müssen mit einer CE‑Kennzeichnung versehen werden.“

Die Richter interpretieren die Leitlinie MEDDEV 2.1/6 sogar wie folgt:

„In diesen Leitlinien heißt es weiter, dass Software, die auf die Daten in keiner Weise einwirkt oder die sich auf die Speicherung, Archivierung, verlustfreie Komprimierung oder letztlich auf die einfache Suche beschränkt, d. h. in diesem letzteren Fall Software, die eine Datenbankfunktion hat und anhand derer aus Metadaten stammende Informationen gefunden werden können, ohne sie zu verändern oder sie zu interpretieren, nicht als Medizinprodukt angesehen werden darf.“ (Hervorhebung durch Johner Institut)

Weiterhin steht in dem Urteil:

„Insoweit bestätigen die in Rn. 33 des vorliegenden Urteils genannten Leitlinien der Kommission in Titel 4 („Module“) im Wesentlichen, dass, wenn eine Software aus Modulen besteht, die der Definition des Begriffs „Medizinprodukt“ entsprechen, und solchen, die dieser Definition nicht entsprechen, nur die erstgenannten Module mit einer CE‑Kennzeichnung versehen werden müssen, da die anderen den Bestimmungen dieser Richtlinie nicht unterliegen. Diese Leitlinien stellen klar, dass es Sache des Herstellers ist, die Grenzen und Schnittstellen der verschiedenen Module anzugeben. Diese müssen, was die der Richtlinie 93/42 unterliegenden Module anbelangt, vom Hersteller eindeutig angegeben werden und auf der künftigen Verwendung des Produkts beruhen.

Der Hersteller einer solchen Software ist daher verpflichtet, diejenigen Module anzugeben, die Medizinprodukte darstellen, damit die CE‑Kennzeichnung allein auf diesen Modulen angebracht werden kann.“

Zusammenfassung

1. Eine Software kann aus verschiedenen Modulen bestehen, bei denen nur bestimmte Module als Medizinprodukte zu zertifizieren sind.
2. Der Hersteller muss diese Module angeben und auf diesen Modulen eine CE-Kennzeichnung anbringen.
3. Der Hersteller muss die Grenzen zwischen diesen Modulen klar identifizieren, wobei die Aufteilung auf der Zweckbestimmung zu basieren hat (s. Seite 18, vorletzter Absatz der MDDEV 2.1/6).

3. Bewertung

a) Rechtssicherheit liegt vor

Das Johner Institut vertrat wie einige Benannte Stellen die Meinung, dass Hersteller ein Produkt entweder als Medizinprodukt oder als Nicht-Medizinprodukt in Verkehr bringen können. Es vermutete, dass die Autoren der MEDDEV 2.1/6 die Begriffe wie „Modul“ anders verstehen als Software-Entwickler. Sätze wie der folgende verstärkten den Eindruck einer eigenen Begriffswelt:

„Computer programmes(sic!) used in healthcare mostly have applications which consist of both medical device and non-medical device modules.“

Die EuGH-Richter sind jedoch der MEDDEV gefolgt, sodass nun eine klare Rechtssprechung vorliegt. Die Definition dessen, was ein Modul ist, haben die Richter aber nicht geliefert. Sind es Komponenten, wie sie ein Software-Entwickler versteht, die (unverzichtbarer) Teil einer Software sind? Oder sind es Plugins, die man zusätzlich und optional installieren kann?

Man muss aber auch den Hintergrund des Urteils verstehen: Der französische Staat will eine bestimmte Software regulieren. Philips möchte ihm das nicht zugestehen, weil das Produkt CE-gekennzeichnet und somit von weiterer Regulierung ausgeschlossen ist. Der Gerichtshof sagt: In diesem Fall hat der französische Staat recht, weil die Software zum großen Teil kein Medizinprodukt ist. Also ganz speziell für ein Produkt, ein KIS, bei dem wirklich große Teile, die auch separierbar sind, kein Medizinprodukt sind.

b) Vorteile durch das Urteil

Herstellern von Standalone-Software können mit Veröffentlichung des Urteils von der Möglichkeit Gebrauch machen, nur die Module einer Software als Medizinprodukt zu zertifizieren, die über eine entsprechende Zweckbestimmung verfügen. Das empfiehlt sich in folgenden Situationen:

• Es gibt im Vergleich zur gesamten Software nur wenige oder/und nur kleine Module mit einer medizinischen Zweckbestimmung.
• Die Module sind nach (medizinischen) Funktionen gebildet und ausreichend stark voneinander abgetrennt.
• Der Aufwand für die Zertifizierung der gesamten Software ist für den Hersteller nicht leistbar.

Das Johner Institut erkennt einige Gründe an, die für die Entscheidung des EuGH sprechen:

• Die Entscheidung kann im Hinblick auf eine Deregulierung und als Gegengewicht zur fatalen Regel 11 der MDR für Hersteller hilfreich sein.
• Sie folgt dem Trend, dass sich Medizinprodukte zunehmend öffnen bis  „auflösen“ und Betreiber die Komponenten (verschiedener Hersteller) zu Systemen kombinieren.
• Die Hersteller werden damit stärker gezwungen, in funktionalen und schwach gekoppelten Komponenten zu denken. Das verbessert die Software-Architektur und damit die Stabilität, Wartbarkeit und Testbarkeit.

c) Herausforderungen und Risiken

Hersteller, die diese Möglichkeit nutzen, sollten sich jedoch der Konsequenzen bewusst sein:

• Risikomanagement
  Es dürfte zumindest schwierig werden, im Risikomanagement zu argumentieren, dass die Risiken beherrscht sind, wenn die Daten, die ein zertifiziertes Modul nutzt, von Modulen stammen, über deren Güte keine ausreichende Aussage getroffen werden kann, weil die Dokumentation des jeweiligen Software-Lebenszyklus (gemäß IEC 62304) nicht vorliegt.
• Usability
  Die Gebrauchstauglichkeit eines Moduls lässt sich in der Regel nicht einzeln bewerten. Ob die Prüfung eines „Fensters“, eines „Screens“ oder einer Maske (ohne den Kontext der gesamten Software zu betrachten) verlässliche Ergebnisse liefert, erscheint fraglich. Die IEC 62366-1 verlangt, die Gebrauchstauglichkeit entlang der Benutzungsszenarien zu bewerten und nicht für einzelne technische Module oder UI-Elemente.
• „Audit-Sicherheit“
  Software-Entwickler werden anfälliger für Fragen von Auditoren, ob der gerade entwickelte Code zu einem zertifizierten oder zu einem nicht zertifizierten Modul gehört. Viele Entwicklungsabteilungen empfinden bereits Stolz, wenn es gelingt, einen einzigen Satz an „Best Practices“ zu verankern …
• Regulatorische Aufwände
  Wenn mehrere Module, die ein Hersteller gemeinsam in Verkehr bringt, Medizinprodukte sind: Liegt dann gar ein System oder eine Behandlungseinheit vor? Bedarf es einer entsprechenden Erklärung? Dann müsste der Hersteller nicht ein Produkt registrieren, sondern n Module und zusätzlich ein System bzw. eine Behandlungseinheit.
• Software-Lebenszyklus und Dokumentation
  Die Aufteilung in Module, die jeweils einzelne Medizinprodukte sind, ermöglicht es, die Module auch unabhängig voneinander zu entwickeln. Doch dies erfordert für jedes Medizinprodukt eine eigene Dokumentation sowie eine eigene Zweckbestimmung, Risikomanagementakte, Software-Lebenzyklusakte, Konformitätserklärung, Handbücher/Gebrauchsanweisungen, klinische Bewertung usw. Über die Herausforderungen beim Usability Engineering wurde bereits gesprochen.
• Labeling
  Wo man die CE-Kennzeichnung im Fall von einzelnen Modulen konform mit den Anforderungen der MDD und MDR anbringen kann und soll, haben die Richter nicht diskutiert. Wie soll das bei einem Modul ohne Benutzerschnittstelle erfolgen?

Die Möglichkeit, die Software-Dokumentation auf die „kritischen“ Module/Komponenten zu beschränken, gibt die IEC 62304 bereits heute. Dass eine möglicherweise einfachere Argumentation bezüglich Segregation der Software-Komponenten die zusätzlichen Aufwände für die Inverkehrbringung von einzelnen Modulen als Medizinprodukt rechtfertigt, kann bezweifelt werden.

Offen bleibt noch die Frage, ob auch das die Komponenten umgebende Produkt ein CE-Zeichen bekommt. Die MDCG schreibt:

This raises the issue as to whether the whole product can be CE marked when not all applications have a medical purpose.

MDCG 2019-11

d) Eine Verschiebung der Ebenen

Wer es absurd findet, dass ein Software-Modul ein Medizinprodukt sein kann, möge sich an die ersten Diskussionen erinnern, ob eine Standalone-Software ein Medizinprodukt sein kann. Denn eine Standalone-Software kann ohne eine Plattform (Hardware, Betriebssystem, ggf. ‚Runtime Environment‘) nicht funktionieren und benötigt die technischen Interfaces der Plattform (Monitor, Tastatur, Touch, Datenschnittstellen …). Niemand stellt inzwischen infrage, dass eine Standalone-Software ein Medizinprodukt sein kann.

Für ein Software-Modul als Medizinprodukt wird die Grenze zwischen Medizinprodukt und Umgebung (Plattform) um eine weitere Ebene verschoben.

Das Modul als Medizinprodukt benötigt als erste Umgebungsebene nun das proprietäre Softwaresystem, das wiederum das Betriebssystem und dieses wiederum die Hardware. Die technische Dokumentation für die Module (= Medizinprodukte) muss diese erweiterte Laufzeitumgebung spezifizieren.

Bei der Verifizierung, dem Testen, muss in Analogie zur Standalone-Software auch das Softwaresystem berücksichtigt werden, so wie man das Betriebssystem und die Plattform beim Standalone-Softwareprodukt berücksichtigen muss.

e) Fazit

Die FDA hat längst mit der Deregulierung begonnen. Dass aus Europa (endlich) ein vergleichbares Signal kommt, ist gut. Die Entscheidung des EuGH eröffnet Herstellern neue Möglichkeiten und erleichtert es, Produkte und Systeme aus Modulen zu kombinieren.

Ob der Aufwand für die Zulassung von einem oder mehreren Modulen als Medizinprodukt tatsächlich geringer ist als der Aufwand für die Zulassung der gesamten Software (die diese Module enthält), ist fraglich und im Einzelfall zu prüfen. In der Regel sei von dem Weg, den der EuGH eröffnet hat, abgeraten.

Es ist zu befürchten, dass die Motivation des Urteils zu einer Entscheidung geführt hat, die in der Praxis mehr Probleme aufwerfen wird, als dass sie Erleichterung verschafft.

Änderungshistorie

• 2023-11-17: Absatz mit ChatGPT aktualisiert aufgrund der Meldung von E-Health-Com
• 2023-02-03: Absatz mit ChatGPT eingefügt. Redaktionelle Änderungen
• 2022-16: Unter „Entscheidungshilfen“ Digital Health Policy Navigator verlinkt
• 2022-09: Unter C) aktuelles MHRA-Dokument ergänzt
• 2022-09: Unter C) 13 Guidance der australischen TGA ergänzt
• 2022-08: Abschnitt „B) Qualifizierung / Klassifizierung von Software als Medizinprodukt“ aktualisiert
• 2020-12: Im Kapitel „13. Australien“ die Ergebnisse des Feedback-Prozesses eingearbeitet