Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Software als Medizinprodukt: Definitionen und Klassifizierungshilfen

Dienstag 20. Oktober 2015

Bei Software als Medizinprodukt unterscheidet man standalone (eigenständige) Software und Software, die Teil eines Medizinprodukts ist. Besonders bei standalone Software fällt die Klassifizierung oft schwer, ob sie als Medizinprodukt einzuordnen ist (in diesem Falle auch SaMD — Software as Medical Device genannt) .

Update: Die MEDDEV 2.1/6 ist im Juli 2016 (neu) erschienen (mehr)

Software im Medizinprodukteumfeld

Klassifzierung von Software als Medizinprodukt

Bei der Klassifizierung von Software als Medizinprodukt gibt es vier Optionen. Zum Vergrößern klicken.

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.

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

Wann Software als Medizinprodukt zu klassifizieren ist

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:

  1. Der Hersteller sagt: diese 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. 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.

Klassifizierung von Software als Medizinprodukt: Wer 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 wir Ihnen im Folgenden vorstellen. Ob diese wirklich hilfreich sind, entscheiden Sie selbst.

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:

  1. Das Bundesinstitut für Arzneimittel und Medizinprodukte BfArM (Die Reaktionszeit ist aber nicht immer schnell, um es vorsichtig zu sagen).
  2. Benannte Stellen. Hier kann ich Ihnen Kontakte verschaffen.
  3. An uns. Wir beantworten ständig solche Fragestellungen. Schnell und kompetent.
Prof. Dr. Christian Johner
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!

Software als Medizinprodukt: Entscheidungshilfen zur Klassifizierung

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:

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

Software als Medizinprodukt: Auch dieses Flussdiagramm gibt nicht immer eine Antwort bei der Klassifizierung

Vollständiges PDF-Dokument

Ich bin noch etwas unschlüssig, was ich davon halten soll. Einerseits steht da 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:

  • Picture Archiving and Communication Systems
  • A mobile application for processing ECGs
  • A mobile application for the communication between patient and caregivers while giving birth
  • A mobile medical application for viewing the anatomy of the human body

3. Medicines and Healthcare Products Regulatory Agency

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

Nun gibt es noch ein Dokument des International Medical Device Regulator Forums IMDRF. Es definiert die 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 10 Seiten angenehm kurz und einen Blick wert.

Interessant bei diesem Artikel zur Klassifizierung ist die Tatsache, dass er sich einerseits weitgehend auf Begriffsdefinitionen beschränkt, andererseits dabei aber auf bereits bestehende Begriffe zurückgreift bzw. diese nur wiederholt. Eine Differenzierung zwischen einem „SaMD Manufacturer“ und einem „Manufacturer“ ergibt sich daraus nicht. Nur was ist dann die Wertschöpfung? Vielleicht die Erkenntnis, dass Software eben nicht anders zu behandeln ist.

Für mich interessant waren v.a. 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 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.
  • Software als Bestandteil eines Medizinprodukts, also Gerätesoftware.
  • Software, die selbst ein Medizinprodukt ist.
  • Software, die ein Zubehör darstellt

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

Entscheidungsbaum der MEDDEV 2.1/6

Das Dokument zählt zu den unglücklichen, da es mehr Fragen aufwirft als beantwortet. Besonders ärgerlich ist die Behauptung, man können Software-Module einzeln CE-kennzeichnen. Die MEDDEV hantiert leichtfertig mit nicht definierten Begriffen. Sätze wie die folgenden lassen nur den Schluss zu, dass die Autoren mit Software bisher nur als Anwender in Berührung gekommen sind:

  • „Some stand alone software may break down into a significant number of applications…“
  • „Computer programmes (sic!) used in healthcare mostly have applications which consist of both medical device and non-medical device modules.“

Diese Aussagen werden die Hersteller natürlich in ihrem Sinn aufgreifen. Da kommt auf die Auditoren und Beratungsunternehmen wieder einiges an Arbeit zu, um diese missverständlichen (um nicht zu sagen: falschen) Aussagen wieder geradezurücken.

Wer wie die Brüssler Behörde ständig nach mehr Kompetenzen bei Herstellern und benannten Stellen schreit, sollte… Aber lassen wir das.

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:

  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), 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 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

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.

Leider wiederholt die britische Behörde den Unsinn der MEDDEV 2.1/6: „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“.

10. FDA un der FDASIA Report

Die FDA ist Mitherausgeberin des FDASIA Reports. FDASIA steht für Food an 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:

  1. Nicht-Medizinprodukte
  2. Medizinprodukte, bei denen die FDA die Einhaltung der gesetzlichen Forderungen (z.B. Zulassungsverfahren, Quality Systems Regulations) einfordert, und
  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.

Beispiele für Software als Medizinprodukt

1. Webseite als Medizinprodukt

Heise Online berichtet ü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 goderma (goderma.com/de) führt einen durch einen Fragebogen und erlaubt es, Fotos der eigenen Haut hochzuladen. Innerhalb von 48h bekommt man eine Antwort. Für nur 29 EUR.

Webseite-Medizinprodukt

Ohne in die Diskussion einsteigen zu wollen, welche Vor- und Nachteile so ein Angebot hat, stellt sich schnell die Frage, ob eine/diese Webseite ein Medizinprodukt ist. Webseiten können generell Medizinprodukte sein. Beispiele dafür habe ich in diesem Blog bereits genannt. 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 von goderma ist die Diagnose von Hautkrankheiten.

Bei genauerem Überlegen wird man aber zum Schluss kommen, dass der vom Hersteller beabsichtigte Zweck der Webseite darin besteht, Informationen zu sammeln und den Workflow der Firma zu unterstützen. Damit wäre die Webseite kein Medizinprodukt. Anders wäre es, wenn die Software dazu bestimmt wäre, die Bilder vorauszuwerten, Größen von Hautläsionen zu berechnen, Scores zu ermitteln oder die Ärzte in einer anderen Weise bei der Diagnose direkt zu unterstützen.

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

2. Webservice als Medizinprodukt

Ein treuer Leser meines Blogs machte mich auf einen Webdienst aufmerksam, der eine API für medizinische Diagnosen bietet: http://www.programmableweb.com/api/promedas

Auf der Webseite des Herstellers heißt 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 ersten Fragen, die man mir stellt:

  1. Ist dieser Web-Service selbst schon ein Medizinprodukt?
  2. Wenn man diesen Webservice in eigene Software integriert, wie muss man diesen Webservice dann normgerecht behandeln? Als SOUP?
  3. Wenn dieser Webservice eine einfache GUI hat, wie in dem Demo-/Live-System, dann kann er doch schon 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, in dem steht, 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 und damit müsste er doch auch die FDA-Anforderungen erfüllen, oder?

Meine Gedanken dazu:

  1. Nein, der Webservice ist kein Medizinprodukt, denn er selbst dient nicht der Diagnose oder Behandlung von Patienten, sondern der Integration in ein System, das der Diagnose oder Behandlung dient.
  2. Nein, eine SOUP ist Teil des Medizinprodukts. Hier haben wir es mit einer Datenschnittstelle zu tun, die einen externen Dienst nutzt. Im Rahmen des Risikomanagements wäre diese natürlich zu bewerten.
  3. Über einen Ausschluss in der Zweckbestimmung wäre man bereits aus dem Schneider. Wenn eine Behörde Stress macht, 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

Ein Mitglied im Auditgarant hat mir die Frage gestellt, ob Dokumentenmanagementsysteme DMS Medizinprodukte seien. Er argumentiert, 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 ein Medizinprodukt gemäß Definition MPG.

Ü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 oder Hilfe des Produkts, auf seiner Webseite oder in Marketingmaterialien, auf Messen und sogar in Gesprächen.

Daher empfehle ich 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 meine kostenlose Auditsprechstunde.

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 aber nicht die die Gefährdung, sondern nur die Übereinstimmung mit der Definition.

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

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 – so meine Prognose – mittelfristig alle KIS ein 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.
  • usw.

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.

Wie bewertet die FDA diese Systeme?
Professor Stettin, sicher einer der gefragtesten Experten und FDA-Insider, gibt eine Antwort auf diese Frage. Hören Sie rein!

Sie möchten mehr über die Forderungen der FDA oder über die Konsequenzen einer Klassifizierung als Medizinprodukt wissen? Im Auditgarant finden Sie schnell Antworten.


Kategorien: Beliebteste Beiträge, Regulatory Affairs, Software & IEC 62304
Tags: , , ,

3 Kommentare über “Software als Medizinprodukt: Definitionen und Klassifizierungshilfen”

  1. Pierre Baum schrieb:

    Hallo Herr Johner,

    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.

    Viele grüße,
    Pierre Baum

  2. Regina Preysing schrieb:

    Hallo Herr Prof. Johner,

    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?

    Vielen Dank und viele Grüße
    Regina Preysing

  3. Prof. Dr. Christian Johner schrieb:

    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.
    Herzliche Grüße, Christian Johner

Kommentar schreiben