Software als Medizinprodukt: Definitionen und Klassifizierungshilfen

Montag 16. Juli 2018

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

UpdateDer EuGH hat ein wichtiges Urteil zur Zertifizierbarkeit von Software-Modulen als Medizinprodukt gesprochen (mehr…)

A) 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.
Klassifzierung von Software als Medizinprodukt

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.

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:

  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.

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

C) 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 Alond 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.

Software Medizinprodukt Modul

Abb. 2: In dieser standalone Software sind nur einige Module als Medizinprodukte zugelassen.

Weiterführende Informationen

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.

Software, die aus Modulen besteht, wobei die Software als ganzes und nicht die einzelnen Module als Medizinprodukt zertifiziert sind

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

Download

Sie können sich das Urteil hier herunterladen.

Zusammenfassung

  1. Eine Software kann aus verschiedenen Modulen bestehen, bei denen nur bestimmte Module als Medizinprodukte zu zertifizieren sind.
  2. Die Hersteller müssen diese Module angeben und eine CE-Kennzeichnung auf diesen Modulen 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).
Vorsicht!

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

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

  • Risikomanagement
    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.
  • 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 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ärungHandbü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?
Vorsicht!

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

Software-Module versus Medizinprodukt

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.

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

D) Entscheidungshilfen zur Klassifizierung von Software als Medizinprodukt

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

Abb. 5: Ausschnitt aus dem COICR Dokument

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
  • Mobile application for processing ECGs
  • Mobile application for the communication between patient and caregivers while giving birth
  • And 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:

  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. Dann Software als Bestandteil eines Medizinprodukts, also Gerätesoftware.
  3. Software, die selbst ein Medizinprodukt ist.
  4. Schließlich 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

Abb. 6: Flussdiagramm der MEDDEV 2.1/6 (zum Vergrößern klicken)

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.

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

10. FDA und der 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:

  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.

11. FD&C sowie FDA

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.

Weiterführende Informationen

Lesen Sie hier mehr zum FDA Guidance Document on Decision Support Systems

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

Webseite-Medizinprodukt

Abb. 7: Webseite als 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

Beispiel

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.

Fragestellungen

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

Bewertung

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

14 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

  4. Christian Sauter schrieb:

    Hallo,
    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 ….

    viele Grüße
    Christian

  5. Christos Freris schrieb:

    Hallo Herr Prof. Johner,

    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?

    Vielen Dank im Voraus
    Christos Freris

  6. Prof. Dr. Christian Johner schrieb:

    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.

    Viele Grüße, Christian Johner

  7. Christos Freris schrieb:

    Sehr geehrter Herr Prof. Johner,

    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!

    Vielen Dank
    Christos Freris

  8. Prof. Dr. Christian Johner schrieb:

    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?

    Beste Grüße, Christian Johner

  9. Matthias Marzinko schrieb:

    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.
    Quelle:
    https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM605683.pdf

  10. Prof. Dr. Christian Johner schrieb:

    Danke für diese Ergänzung, Herr Marzinko!

    Eine kurze Beschreibung, was dieses Dokument aussagt finden Sie auch hier.

  11. Dr. Klaus Ellinger schrieb:

    Newsletter Abo

  12. Roland Weghorn schrieb:

    Sehr geehrter Herr Prof. Johner,

    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.

    Herzliche Grüße
    Roland Weghorn

  13. Prof. Dr. Christian Johner schrieb:

    Sehr geehrter Herr Weghorn,

    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.

    Viele Grüße, Christian Johner

  14. Roland Weghorn schrieb:

    Vielen Dank Herr Prof. Johner. Wenn das reicht, ist alles gut.

Kommentar schreiben