Source: https://www.johner-institut.de/blog/regulatory-affairs/software-als-medizinprodukt-definition/?share=google-plus-1
Timestamp: 2019-05-26 06:59:17
Document Index: 214739569

Matched Legal Cases: ['§3', 'EuG', 'EuG', 'EuG', 'Art. 1', 'EuG', 'EuG', 'EuG', 'EuG', 'EuG']

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 und
(eigenständige) Software, die kein Medizinprodukt ist.
Abb. 1: Bei der Klassifizierung von Software als Medizinprodukt gibt es vier Optionen (zum Vergrößern klicken)
Abhängig von dieser Klassifizierung müssen Sie als Hersteller unterschiedliche Regularien beachten. Dieser Artikel hilft Ihnen, Ihre Software richtig zu klassifizieren.
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.
Definition: Software as Medical Device
„software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device“
Quelle: IMDRF/SaMD WG/N12FINAL:2014
Nach Auskunft des deutschen Bundesgesundheitsministerium ist im Leitfaden zur MDR folgende Definition des Begriffs medizinische Software geplant, wie er von der MDCG erarbeitet wird:
Definition: Medical device software
„Medical device software (MDSW) is all software that is intended to be used, alone or in combination, for a medical purpose specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or is driving or influencing the use of a device.”
Quelle; MDCG
Diese neue Definition soll offensichtlich sowohl die sogenannte „independent software“ (also die standalone Software) als auch die Steuerungssoftware (oft auch als Funktionssoftware bezeichnet) umfassen. Diese Differenzierung nahm bereits die MDD vor.
Durch den Zusatz „regardless of whether the software is independent or is driving or influencing the use of a device“ könnte der Anschein entstehen, dass die strenge Klassifizierungsregel 11 des Kapitels III des Anhangs VIII der MDR sowohl für die Stand-alone Software als auch für die Steuerungssoftware gelten soll.
Das ist jedoch nicht der Fall: Aus der Tatsache, dass beide Typen von Software als Medizinprodukt klassifiziert werden, darf nicht geschlossen werden, dass für beide die Regel 11 anwendbar ist. Vielmehr sind zwei Fälle bei der Klassifizierung nach MDR (nicht Klassifizierung als Medizinprodukt) zu unterscheiden:
Die Software „drives a device or influences the use of a device“: Die Klassifizierung der Software entspricht der des „beeinflussten Medizinproduktes unabhängig von der Regel 11.
„Independent of any other device“ ist: Die Klassifizierung der Software geschieht durch Anwender der Regel 11.
Die Klassifizierung nach MDR erfolgt daher nicht „regardless“ sondern „depends of whether the software is independent or is driving or influencing the use of a device.“
Danke an Sonia Gabrielszyk von der Kanzlei Dierks + Company für Anregungen und Formulierungen!
B) Klassifizierung von Software als Medizinprodukt
Die Zweckbestimmung des Herstellers entscheidet…
Die Frage, wann Software als Medizinprodukt zu klassifizieren ist, stellt sich nur bei standalone Software. Die kurze Antwort lautet: 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äß §3 MPG entspricht.
… und nicht primär die Funktionen der Software
Entscheidend bei der Klassifizierung ist also die Zweckbestimmung durch den Hersteller und weniger die Funktionen der Software. Zu einer Software, die Vitalparameter erfasst, ließe sich diesbezüglich auf zwei Weisen argumentieren, die zu unterschiedlichen Klassifizierungen führen:
Der Hersteller sagt: diese Erfassung dient nur der Dokumentation. Dann ist das Produkt kein Medizinprodukt.
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. s.o.) und aus den Funktionen(!) den vom Hersteller vorgesehenen Gebrauch (Zweckbestimmung) abzuleiten. Ob die Schlussfolgerungen des Gutachters dann immer in Ihrem Sinn sind, darf bezweifelt werden.
Wer über die 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 klassifizieren 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 Klassifizierung von Software als Medizinprodukt final beantworten.
Dazu wird der Richter einen Gutachter beauftragen. Dieser wird beim Erstellen des Gutachtens prüfen, ob die Software der Definition des Begriffs Medizinprodukt entspricht, sprich: ob sie (verkürzt gesagt) der Diagnose, Behandlung oder Überwachung von Krankheiten und Verletzungen dient.
Wenn Sie unsicher sind, ob Ihre Software ein Medizinprodukt ist, dann wenden Sie sich an:
Das Bundesinstitut für Arzneimittel und Medizinprodukte BfArM (Die Reaktionszeit ist aber nicht immer schnell, um es vorsichtig zu sagen).
Benannte Stellen. Hier kann ich Ihnen Kontakte verschaffen.
An uns. Wir beantworten ständig solche Fragestellungen und erstellen Gutachten. Schnell und kompetent.
Sind Sie unsicher, ob Ihre medizinische Software ein Medizinprodukt ist? Benötigen Sie ein Gutachten? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!
C) Entscheidungshilfen zur 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 dazu eine Reihe von Dokumenten veröffentlicht, die als Entscheidungshilfen dienen sollen. Wir stellen Ihnen folgende Dokumente vor:
COICR Contribution
EU: Manual on Borderline and Classification
International Medical Device Regulator Forum IMDRF
MEDDEV 2.1.6
Asian Harmonization Working Group
Britische MHRA
FDA und FDASIA Report
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.
Abb. 5: Ausschnitt aus dem COICR 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 die Arbeit gemacht, um Hersteller und Entwickler zu unterstützen.
2. EU: Manual on Borderline and Classification
Von der EU stammt ein „Manual“, das anhand von Beispielen versucht, Medizinprodukte von Nicht-Medizinprodukten zu unterscheiden und Hilfe bei der Klassifizierung zu geben. Die Beispiele beziehen sich teilweise auch auf Software:
And mobile medical application for viewing the anatomy of the human body
Weiterhin hat die britische „Medicines and Healthcare Products Regulatory Agency“ ein Dokument mit dem Titel „Borderlines with medical devices“ herausgegeben. Lesen Sie mal im Kapitel 9 des Dokumentes den Satz zu den „Telecare Alarm Systems“. Ich wäre an Ihrer Einschätzung interessiert.
4. IMDRF
Zu den sehr relevanten Dokumenten zählt das Dokument des International Medical Device Regulator Forums IMDRF. Es definiert die Begriffe
SaMD Changes
SaMD Manufacturer
Intended Use / Intended Purpose
Das Dokument ist mit 10 Seiten angenehm kurz und einen Blick wert.
Interessant sind zum einen 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
ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes —
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 wie 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 Klassifizierung von Software als Medizinprodukt sind, lässt sich sicher trefflich diskutieren. Schließlich geht die Hilfestellung bei der Klassifizierung nicht entscheidend über die Definition des Begriffs Medizinprodukt hinaus.
5. MEDDEV 2.1.6
Die MEDDEV 2.1/6 hat im Juli 2016 die aktuellste Version des Dokuments 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:
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.
Dann Software als Bestandteil eines Medizinprodukts, also Gerätesoftware.
Software, die selbst ein Medizinprodukt ist.
Schließlich Software, die ein Zubehör darstellt
Ein im Vergleich zur 2012er Version überarbeiteter Entscheidungsbaum soll helfen, die richtige Klasse zu bestimmen:
Abb. 6: Flussdiagramm der MEDDEV 2.1/6 (zum Vergrößern klicken)
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.
Lesen Sie hier mehr zum Thema Klassifizierung von IVD Software.
6. Schwedische Behörden
Von den schwedischen Behörden „Medical Information Systems – guidance for qualification and classification of standalone software with a medical purpose“.
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:
Software, die Teil eines Medizinprodukts ist (oft als embedded Software bezeichnet)
(standalone) Software, die ein Zubehör für ein Medizinprodukt ist z.B. zum Weiterleiten von Daten
Standalone Software, die selbst ein Medizinprodukt ist (Software as a Medical Device SaMD), die auf Datenträger, per Download oder webbasiert zur Verfügung gestellt wird.
Im weiteren 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 (siehe oben)
Die Australia „Therapeutic Goods Association“ (TGA) referenziert selbst wieder europäische und US-amerikanische Veröffentlichungen. Sie klassifiziert Dokumentations-Software nicht als Medizinprodukt, ebenso 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 chinesische 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 (siehe oben) 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. Wieder nennt eine Tabelle konkrete Beispiele dafür.
Zu den Vorgaben des japanischen MHLW (Ministry of Health, Labor and Welfare) steht geschrieben, dass standalone Software ein Medizinprodukt sein kann und dass weitere Empfehlungen gerade erarbeitet würden.
Eine Übersicht über die Vorgaben der FDA (siehe oben) schließt den Reigen der untersuchten Rechtsbereiche ab.
In der Zusammenfassung fasst 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 Eigenstä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
Im Sommer 2016 hat auch die Medical Health Products Regulatory Agency eine „Entscheidungshilfe“ herausgegeben. Das interaktive PDF der MHRA soll bei der Entscheidung helfen, ob Software als Medizinprodukt zu klassifizieren ist und in welche Klasse gemäß MDD diese Software dann fällt. Wirklich neu ist eher die Form der Darstellung als der Inhalt.
Die britische Behörde greift die Gedanken der MEDDEV 2.1/6 auf: „In complex systems it may be appropriate to CE mark only those functions that meet the definition of a
device rather than CE marking the whole product. See section 4 of MEDDEV 2.1/6″.
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 zur 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.“
In diesem Bericht unterscheidet die FDA erneut (wie im Guidance-Dokument zu den Mobile Medical Apps) zwischen:
Medizinprodukte, bei denen die FDA die Einhaltung der gesetzlichen Forderungen (z.B. Zulassungsverfahren, Quality Systems Regulations) einfordert, und
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:
Evidence-based clinician order sets tailored for a particular condition, disease, or clinician preference;
Drug-drug interaction and drug-allergy contraindication alerts to avert adverse drug events;
Most drug dosing calculations;
Drug formulary guidelines;
Reminders for preventative care (e.g. mammography, colonoscopy, immunizations, etc.);
Facilitation of access to treatment guidelines and other reference material that can provide information relevant to particular patients;
Calculation of prediction rules and severity of illness assessments (e.g., APACHE score, AHRQ Pneumonia Severity Index, Charlson Index);
Duplicate testing alerts;
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.
Achtung! Durch die im nächsten Abschnitt erwähnte Änderung der Section 520 des Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360j) muss die FDA einige Guidance Documents umschreiben, insbesondere die zu Medical Device Data Systems MDDS und zu Mobile Medical Apps.
Ein neues Guidance Document 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 dienen, 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 Documents überarbeiten.
Mehr dazu erfahren Sie diesem Draft Guidance der FDA zu „Existing Medical Software Policies“.
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 sich bemüßigt gefühlt hat, im Dezember 2017 ein Guidance Document zu veröffentlichen, 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.
Lesen Sie hier mehr zum FDA Guidance Document on Decision Support Systems
Health Canada hat einen Entwurf eines „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 klassifiziert 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
Software, die Zugang zu Literaturdaten verschafft
Software, die vor Medikamentenwechselwirkungen warnt
Software, die keine unmittelbare Handlungen auslöst
Software für einfache medizinische Berechnungen
c) Risiko-Klassifizierung
Bei der Risikoklassifizierung lehnt sich Health Canada ebenfalls an das IMDRF Dokument an, erlaubt aber an manchen Stellen eine niedrigere Klassifizierung.
D) Beispiele für Software als Medizinprodukt
1. Webseite als Medizinprodukt
Heise Online berichtete über ein Start-up, dessen Geschäftsidee darin besteht, für einen Betrag Diagnosen von Hautkrankheiten über das Internet zu erstellen. Die Webseite der Firma führte einen durch einen Fragebogen und erlaubte es, Fotos der eigenen Haut hochzuladen. Innerhalb von 48h bekam man eine Antwort. Für nur 29 EUR. Die Webseite ist inzwischen offline.
Abb. 7: Webseite als Medizinprodukt
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?
Die 2007/47 hat klar gestellt, 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: http://www.programmableweb.com/api/promedas
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.
Damit ergeben sich gleich die Fragen wie die folgenden:
Ist dieser Web-Service selbst schon ein Medizinprodukt?
Wenn man diesen Webservice in eigene Software integriert, wie muss man diesen Webservice dann normgerecht behandeln? Als SOUP?
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?
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 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.
Es gibt noch weitere Möglichkeiten, um eine Komponente, die als Medizinprodukt klassifiziert ist, in ein Produkt zu integrieren, ohne dieses Produkt „zu infizieren“, d.h. dieses ebenfalls zum Medizinprodukt zu machen.
Wenn Sie weitere Informationen wünschen, dann nehmen Sie gerne Kontakt mit uns auf.
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
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 letztliche Entscheidung treffen.
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 Patienten verletzen oder schädigen.
Relevant ist hingegen, was der Hersteller sagt, für was seine Kunden das Produkt nutzen können und sollen. Wenn der Hersteller sagt, dass das System nur der Dokumentation dient, ist dieses System 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
In Marketingmaterialien wie Flyern
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
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. Beispielsweise 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 System weiterleiten.
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 rein 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 werden. 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 Medizinproduktebetreiberverordnung. Und diese verlangt beispielsweise, dass
Personen, welche das System anwenden, betreiben und instandhalten, geschult sein müssen. Das gilt es zu dokumentieren.
das System regelmäßig, spätestens alle zwei Jahre überprüft werden muss,
nach jeder Instandhaltungsmaßnahme (Software-Update) alle sicherheitsrelevanten Funktionen und Konstruktionsmerkmale geprüft werden müssen.
Doch wie sollen Krankenhäuser dies bewerkstelligen? Wie sollen sie vollständig prüfen, dass nach einem Software-Update das 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 die Ultraschallgeräte gibt, welche 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.
Software als IVD
Software kann nicht nur als Medizinprodukt (gemäß MDD/MDR), sondern auch als IVD (gemäß IVDD/IVDR) klassifiziert werden.
Lesen Sie hier mehr zum Thema IVD Software.
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.“
Ein Beispiel für solch eine Software könnte ein Krankenhaus-Informationssystem darstellen, das aus Nicht-Medizinproduktemodulen (Abrechnung, Stammdatenverwaltung usw.) und Medizinproduktemodulen (z.B. Arzneimittelprüfung, radiologische Befundung) besteht.
Abb. 2: In dieser standalone Software sind nur einige Module als Medizinprodukte zugelassen.
Lesen Sie hier mehr zum Thema Software-Module bzw. Software-Komponenten.
In den meisten Fällen wird man die standalone Software als Ganzes als Medizinprodukt zertifizieren und nicht deren einzelne Komponenten wie beispielsweise eine Software zur Arzneimittelsicherheit. Hier würde man nicht anstreben, einzelne Module zu zertifizieren.
Abb. 3: Software, die aus Modulen besteht, wobei die Software als ganzes und nicht die einzelnen Module als Medizinprodukt zertifiziert sind
2. Bestätigung durch das EuGH
Es wurde ein EuGH-Urteil vom Dezember 2017 veröffentlicht, das die Möglichkeit bestätigt, Softwaremodule mit/ohne Medizinprodukteeigenschaft 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.“ (Fettung durch Johner Institut)
Weiter steht im 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.“
Sie können sich das Urteil hier herunterladen.
Eine Software kann aus verschiedenen Modulen bestehen, bei denen nur bestimmte Module als Medizinprodukte zu zertifizieren sind.
Die Hersteller müssen diese Module angeben und eine CE-Kennzeichnung auf diesen Modulen anbringen.
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).
Das Urteil sollte nicht so verstanden werden, dass standalone Software immer in Module zerlegt werden und dann pro Modul entschieden werden muss, ob es ein Medizinprodukt ist. Die Zerlegung der Software in Komponenten fordert zwar die IEC 62304 (außer für Klasse-A-Software). Aber Hersteller sollten sehr sorgfältig entscheiden, ob sie tatsächlich einzelne Module als Medizinprodukte zertifizieren lassen. In den meisten Fällen rät das Johner Institut davon ab (siehe unten und siehe Beispiel in Abbildung 3).
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, so dass 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. Phillips 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 SW 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 EuGHs 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:
Es dürfte zumindest sehr schwer 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.
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 Medizinprodukte sind, die ein Hersteller gemeinsam in Verkehr bringt: Liegt dann gar ein System oder eine Behandlungseinheit vor? Bedarf es einer entsprechender 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 bedingt für jedes Medizinprodukt eine eigene Dokumentation wie eine eigene Zweckbestimmung, Risikomanagementakte, Software-Lebenzyklusakte, Konformitätserklärung, Handbücher / Gebrauchsanweisungen, klinische Bewertung usw. Über die Herausforderungen beim Usability Engineering wurde bereits gesprochen.
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?
Beachten Sie: Wenn die Hersteller diese Dokumente nicht für jedes Modul und damit n-fach erstellen möchten, wenn sie nicht n-mal eine Post-Market Surveillance durchführen und dokumentieren wollen, müssen sie die Software weiter als ein einziges Produkt in den Verkehr bringen. Doch was haben sie sich dann gespart? Sie haben eine komplette technische Dokumentation erstellt, die es bei der Zulassung eines Medizinprodukts bedarf.
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, lässt sich bezweifeln.
d) Eine Verschiebung der Ebenen
Wer es absurd findet, dass ein Softwaremodul 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 in frage, dass eine standalone Software ein Medizinprodukt sein kann.
Für ein Softwaremodul als Medizinprodukt, wird die Grenze zwischen Medizinprodukt und Umgebung (Plattform) um eine weitere Ebene verschoben.
Abb. 4: Bei standalone Software besteht die Laufzeitumgebung z.B. aus Betriebssystem und Hardware. Das EuGH-Urteil hätte zur Folge, dass die „Basis-Software“ ebenfalls zur Laufzeitumgebung zählt und nur die Module ein Medizinprodukt (MP) sind.
Das Modul als Medizinprodukt benötigt als erste Umgebungsebene nun das proprietäre Softwaresystem, das wiederum das Betriebssystem, und das wiederum die Hardware. Die technische Dokumentation für die Module (= Medizinprodukte) muss diese erweiterte Laufzeitumgebung spezifizieren.
Bei der Verifizierung, dem Testen, müssen ebenfalls 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.
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 einzelne 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 aufwirft als dass sie Erleichterung verschafft.
Kategorien: Beliebteste Beiträge, Regulatory Affairs, Software & IEC 62304
Tags: Klassifizierung von Medizinprodukten, MEDDEV - Medical Devices Dokumente, Medizinprodukt (nach Medizinproduktegesetz) ~ Definition, Standalone Software
23 Kommentare über “Software als Medizinprodukt – Software as Medical Device”
Pierre Baum schrieb:
Dienstag 27. Januar 2015 um 15:21
vielen Dank für die Zusammenfassung der Dokumente. Leider ist der Link zu http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-samd-key-definitions.pdf nicht. Über http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-samd-key-definitions-140901.pdf#search=„samd key definitions“ habe ich es dann gefunden.
Regina Preysing schrieb:
Dienstag 13. Dezember 2016 um 15:03
die Auseinandersetzung mit den unterschiedlichen Anleitungen, wie nun die Produkte zu klassifizieren sind, ist sehr spannend – vor allem unter dem Aspekt, wie das wohl eine Benannte Stelle sieht.
Laut EU Kommission sind die MEDDEV Guidelines rechtlich nicht bindend.
Das BfARM hat aktuell auf seiner Webseite http://www.bfarm.de/DE/Medizinprodukte/Abgrenzung/medical_apps/_node.html zur Klassifizierung auf Anhang IX der Richtlinie 93/42/EWG verwiesen.
Wenn wir dementsprechend in diesem Jahr/Anfang 2017 ein neues Produkt als Klasse I einstufen und entsprechend in den Markt bringen, machen wir dann etwas falsch? Gibt es auch bei den Guidelines eine Übergangsfrist, auf die man sich berufen kann?
Dienstag 13. Dezember 2016 um 21:55
Liebe Frau Preysing,
Stand Dezember 2017 gibt es nur den Anhang IX. Bitte ignorieren Sie noch alle künftigen Klassifizierungen der MDR. Noch ist die nicht verabschiedet. Das wird voraussichtlich Frühsommer 2017. Natürlich sollte man sich auf die MDR vorbereiten. Das wird mehr Arbeit als uns allen lieb ist. Aber noch keine Produkte anders klassifizieren.
Dienstag 2. Januar 2018 um 20:52
meiner Meinung nach steht in der „COICR Contribution“ tatsächlich nichts neues, das ist im Grunde nur die Meddev 2.1/6 noch mal erläutert/abgeschrieben ….
Christos Freris schrieb:
Dienstag 9. Januar 2018 um 10:45
ihre Beiträge samt scharfsinnigen Kommentaren sind sehr informativ und auf dem Punkt! Vielen dank!
Es gibt eine Kategorie von SW, die in keinem Dokument erwähnt wird, zumindest meiner Verständnis nach. Der Unterschied zwischen Embedded und Stand-Alone Software als MD ist mir klar.
Was ist aber mit einem SW-Tool, welches kein MD ist, und nicht von Kunden sondern nur von Service Technikern eingesetzt wird um die SW eines MD zu verändern. Konkretes Beispiel: Ein selbst entwickeltes SW-PC-Tool für die
a. Durchführung eines SW-Updates oder
b. Änderung von individuellen Parametern (Konfiguration-Kalibrierung).
Fällt es unter der Kategorie „Accessory“ obwohl es nicht an Kunden verkauft wird?
Christos Freris
Dienstag 9. Januar 2018 um 12:45
Sehr geehrter Herr Feris,
bei einem solchen Tool handelt es sich in der Tat um ein Zubehör. Allerdings liegt bei Ihnen keine Inverkehrbringung vor. Entsprechend muss kein Konformitätsbewertungsvefahren durchlaufen werden. Die grundlegenden Anforderungen müssen aber erfüllt sein.
Dienstag 9. Januar 2018 um 13:11
vielen Dank für die prompte Reaktion! Ich wollte Ihre Meinung wissen, welche absolut Sinn macht.
Leider war der FDA-Inspektor der Ansicht, es sei „part of the medical device, because it changes the configuration or the whole SW on the device“ und verpasste uns eine 483, weil das Tool als SW Class A von uns eingestuft war anstatt Class C (die der SW des Gerätes). Widerstand zwecklos!
Dienstag 9. Januar 2018 um 21:23
Das tut mir leid, lieber Herr Freris!
Die SW ist ein Zubehör, da irrt der Inspektor wahrscheinlich. Allerdings hat er mit der Klassifizierung möglicherweise Recht. Wenn die SW durch eine Fehlkonfiguration einen nennenswerten Schaden zur Folge haben kann, dann ist die SW Klasse C.
Dass der Inspektor überhaupt von Sicherheitsklassen nach IEC 62304 spricht, überrascht mich. Haben Sie Konformität mit diesem Standard erklärt? Das wäre nicht notwendig gewesen. Oder geht es um den Level of Concern?
Matthias Marzinko schrieb:
Dienstag 10. Juli 2018 um 10:53
Vielen Dank für den sehr interessanten Artikel. Die Ausführungen zu den Modulen deckt sich meines Erachtens auch sehr gut mit der FDA (draft) Guidance vom April 2018: „Multiple Function Device Products: Policy and Considerations“
darin schließt die FDA auch die Bewertung von nicht medizinischen Modulen / Funktionen aus.
https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM605683.pdf
Dienstag 10. Juli 2018 um 13:35
Danke für diese Ergänzung, Herr Marzinko!
Eine kurze Beschreibung, was dieses Dokument aussagt finden Sie auch hier.
Dr. Klaus Ellinger schrieb:
Mittwoch 11. Juli 2018 um 09:51
Roland Weghorn schrieb:
Mittwoch 11. Juli 2018 um 15:07
vielen Dank für den wie immer sehr interessanten Artikel. Eine Frage: Wie muss man sich die CE-Kennzeichnung eines Software-Moduls vorstellen? Hier fehlt mir völlig die Vorstellung.
Für einen Hinweis wäre ich Ihnen sehr dankbar.
Roland Weghorn
Donnerstag 12. Juli 2018 um 14:45
das ist auch schwer vorstellbar. Genau diese Frage stellt der Artikel auch. Ggf. könnte es der Splash-Screen oder das Help>About der übergeordneten Anwendung einen Ansatz bieten.
Freitag 13. Juli 2018 um 09:21
Vielen Dank Herr Prof. Johner. Wenn das reicht, ist alles gut.
Thomas Hertwig schrieb:
Donnerstag 4. Oktober 2018 um 07:38
wir nutzen in der Entwicklung unserer Medizinproduktesoftware Developer-Express-Komponenten. Würden Sie diese eher als zur Laufzeitumgebung (ähnlich wie das .net-Framework) gehörend oder eher als SOUP sehen?
Und wie verhält es sich mit Angular (Laufzeitumgebung)?
Donnerstag 4. Oktober 2018 um 07:49
Lieber Herr Hertwig,
die formale Antwort ist die: Wenn Sie die Komponenten als Teil Ihres Produkts mit ausliefern, sind das SOUP.
Die inhaltliche Antwort: Die DevExp-Komponenten und Angular sind fast immer Teil des Produkts, das setzt man nicht als bereits installiert voraus. Einmal sind diese Komponenten zu spezifisch, zum anderen wollen Sie sicher sein, dass genau die richtigen Versionen genutzt werden. Also: SOUP.
Die praktische Antwort: ein Auditor wird das in der Regeln nicht unterscheiden können.
Anne-Kathrin Lerke schrieb:
Donnerstag 21. März 2019 um 12:31
vielen Dank für Ihren ausführlichen und äußerst interessanten Artikel zum Thema Software als Medizinprodukt.
Wir als IVD-Hersteller stehen im gegenwärtigen Entwicklungsprozess genau vor diesem Problem. Für einen unserer Analyzer gibt es künftig eine neue Software. Damit auch Geräte im Feld von der neuen Software profitieren, wird unsererseits ein Software-Update ermöglicht. Realisiert wird dieses Software-Update durch eine eigens geschriebenen Software, die keinen medizinischen Zweck hat, sondern lediglich eine Update-Funktion. Zudem überprüft sie vor dem Start des Updates, ob die Einstellungen des Analyzers (Datum, Parameter) korrekt sind. Wenn nicht, werden diese Parameter durch die Software entsprechend korrigiert. Somit würde sie in ein Medizinprodukt eingreifen.
Müssen wir die Update-Software als Medizinprodukt klassifizieren, oder genügt die Begründung, dass die Software keinen medizinischen Zweck erfüllt?
Ich danke Ihnen im Voraus für eine Einschätzung.
Anne-Kathrin Lerke
Donnerstag 21. März 2019 um 15:52
Sehr geehrte Frau Lerke,
danke für die spannende Frage! Wenn Sie eine Software schreiben, die speziell dafür gedacht ist, die Software auf Ihrem Medizinprodukt zu aktualisieren, ist das ein Zubehör. Für Zubehör gelten leider die gleichen Regularien wie für Medizinprodukte.
Dienstag 26. März 2019 um 10:48
ich danke Ihnen für die schnelle Antwort, die das bestätigt, was unser RA-Kollege bereits vermutet hat. Insgeheim hatte natürlich noch gehofft, weder in die Kategorie Medizinprodukt noch in die Kategorie Zubehör zu fallen.
Rainer Gutschmidt schrieb:
Freitag 26. April 2019 um 19:47
mobile Produkte, die sogen. wearables sind in aller Munde. Diese oft als smart watch ausgeführten, multifunktionalen Geräte können in der einfachsten Version manuell oder automatisch Notfall-Alarmierungen auslösen.
Ist nach der neuen MDD eine smart watch, die eine Alarmierung bei einem Notdienst auslöst, wenn ein Senior selbst den button drückt oder z.B. per Areal-Überwachung(GPS) einen Dementen außerhalb des Areals erfaßt, damit schon ein Medizinprodukt?
Anders gefragt – wird eine einfache chinesische tracker smart watch, welche nach LVD, EMV und RED die EU-Konformität hatte, durch Implementation einer Senioren-Überwachungs app durch eine Software-Firma in der EU zum Medizinprodukt? Die Konsequenzen einer Fehlfunktion des Geräts könnten sich durchaus lebensbedrohlich auswirken.
Oder bleibt die Konformität der „hardware“ inkl. Betriebssystem zur Kommunikation und Positionsüberwachung nach LVD, EMV und RED bestehen und es muß nur die zugefügte app einer Neubewertung nach MDD unterzogen werden?
Rainer Gutschmidt
Samstag 27. April 2019 um 09:21
Sehr geehrter Herr Gutschmidt,
danke für Ihre Frage zu Klassifizierung und das anschauliche Beispiel!
Die Klassifizierung hängt nicht primär von der Funktionalität, sondern von der Zweckbestimmung ab. Wenn die Zweckbestimmung darin besteht, dass ein dementer Patient überwacht werden soll, dann liegt die Zweckbestimmung in der Überwachung einer Krankheit. Genau das würde unter die Begriffsdefinition „Medizinprodukt“ fallen.
Eine hierfür relevante Änderung der Definition zwischen MDD und MDR (die meinten Sie, oder?), gibt es nicht.
In dem genannten Fall wäre die App das Medizinprodukt, weil die App und nicht die Hardware für die o.g. Zweckbestimmung in den Verkehr gebrach wird. Allerdings muss der Hersteller die Risiken, die sich aus diese Hardware ergeben berücksichtigen und beherrschen.
Der Hersteller ist nicht verpflichtet, für die Hardware (SmartPhone) die EMV zu gewährleisten, da er das Produkt nicht in den Verkehr bringt.
Viele Grüße, Christian Johner.
Peter R. Egli schrieb:
Mittwoch 22. Mai 2019 um 10:17
Bei der Klassifikation von Produkten als Medizinprodukt ja / nein (MEDDEV 2.1/6 spricht hier von Qualification, passt für mich besser als der Begriff Klassifikation, aber leider ist die MEDDEV 2.1/6 nicht mehr anwendbar mit der MDR) sehe ich bei Medizinproduktherstellern immer wieder, dass das Risiko, ob ein Patient geschädigt werden kann, einfliesst in die Entscheidung, ob es sich um ein Medizinprodukt handelt oder nicht. Ich kenne keine einzige Stelle in den einschlägigen Guidelines und Regularien, wo das Risiko als Faktor für die Qualifikation herangezogen werden kann.
Vielleicht habe ich das eine wichtige Dokument nicht gelesen oder den Inhalt nicht verstanden. Können Sie mir einen Hinweis dazu geben, ob das Risiko an sich ein Faktor bei der Qualifikation sein kann oder nicht?
Mittwoch 22. Mai 2019 um 14:52
Sehr geehrter Herr Egli,
danke für die spannende Frage! Sie haben Recht, dass die MEDDEVs unter der MDR nicht mehr gültig sein werden. Ich erwarte allerdings, dass man sich weiter an diesen Leitlinien orientiert, bis man etwas Neues hat.
Dass das Risiko alleine nicht entscheidend ist, halte ich für richtig. Sonst müsste z.B. ein Geländer im Krankenhaus auch als MP klassifiziert werden. Denn wenn es zusammenbricht, ist der Schaden hoch.
Entscheidend ist also weiterhin die Frage, ob das Produkt der Diagnose, Therapie, Überwachung usw. dient.
« Breakthrough Devices Program der FDA
Digital Health & E-Health: Die 7 größten Herausforderungen »