1. Einstufung von Software als Medizinprodukt

Transkript

1 Seite 1 von 14 Vorschlag und Modell zur Bewertung des regulatorischen Status einer Software als mögliches Medizinprodukt Expertenbeitrag von Armin Gärtner Stand Weder die Medizinprodukte-Richtlinie Medical Devices Directive 93/42/EWG (MDD) in der Fassung 2007/47/EG noch das deutsche Medizinproduktegesetz (MPG) beinhalten konkrete Beispiele für eigenständige Software, die als Medizinprodukt zu klassifizieren ist. Aus Sicht der Richtlinie versteht man unter einer eigenständigen Software (auch als Stand-alone-Software bezeichnet) eine Software, die nicht in einem Medizinprodukt implementiert ist und auf verschiedenen Hardware-Plattformen laufen kann. Dieser Beitrag schlägt auf Basis der regulatorischen Definitionen der MDD und der Empfehlungen des MEDDEV-Leitfadens 2.1./6 vom Bewertungskriterien vor, die herangezogen werden können, um zu beurteilen, ob eine Software Funktionen beinhaltet, die eine Einstufung als Medizinprodukt rechtfertigen. Der Beitrag soll deshalb helfen, mit den vorgestellten regulatorischen Vorgaben und Bewertungskriterien eine fundierte und nachvollziehbare Entscheidung zu treffen, ob eine Software als Medizinprodukt nach der MDD einzustufen ist oder nicht. 1. Einstufung von Software als Medizinprodukt Auch wenn die EU-Kommission Software als eigenständiges Medizinprodukt in die Definition des Artikels 1 (2)a der EG-Richtlinie MDD 2007 aufgenommen hat, fehlen derzeit jegliche beispielhafte Ausführungen zu Stand-alone-Software als eigenständigem Medizinprodukt (Ausnahme: MEDDEV-Dokument 2.1/6). Weder die Richtlinie MDD, das MPG, die Medizinproduktebetreiber-Verordnung (MPBetreibV) noch die anderen Verordnungen zum MPG geben weiterführende Auskunft, wann eine Software ein Medizinprodukt ist bzw. welche Kriterien für die regulatorische Einstufung heranzuziehen sind.

2 Seite 2 von 14 Aus dem Richtlinientext der Definition nach Artikel 1 (2)a lässt sich lediglich ableiten, dass Software ein Medizinprodukt ist, wenn der Hersteller sie für die Verwendung für diagnostische und therapeutische Zwecke zur Anwendung am Menschen bestimmt hat. Diese Definition der MDD ist in 3 Abs. 10 MPG (Begriffsbestimmungen) umgesetzt worden. Abbildung 1 zeigt, für welche diagnostischen und therapeutischen Zwecke ein Medizinprodukt und somit eine Stand-alone-Software eingesetzt werden kann. Abbildung 1: Diagnostische und therapeutische Zwecke Medizinprodukt Die EU-Kommission gibt in Ergänzung und zur Präzisierung der EU-Richtlinien sogenannte MEDDEV-Guidelines heraus, die als unverbindliche Leitfäden bestimmte Themengebiete näher erläutern. Bezüglich eigenständiger Software als Medizinprodukt hat die EU-Kommission Anfang 2012 ein neues MEDDEV Dokument (2.1/6) zur Qualifizierung und Klassifizierung von eigenständiger Software als Medizinprodukt herausgebracht. 1.1 MEDDEV 2.1/6 Leitfaden Am 12. Januar 2012 veröffentlichte die EU-Kommission den neuen MEDDEV Leitfaden MEDDEV 2.1/6 GUIDELINES ON THE QUALIFICATION AND CLASSIFICATION OF STAND ALONE SOFTWARE USED IN HEALTHCARE WITHIN THE REGULATORY FRAMEWORK OF MEDICAL DEVICES, der Hilfestellung für die Einstufung und Klassifizierung von Stand-alone Software als mögliches Medizinprodukt gibt. [Quelle 1] MEDDEV-Dokumente (MEDical DEVices) werden durch verschiedene Arbeitsgruppen im Umfeld der EU-Kommission im Konsens erarbeitet, um rechtlich

3 Seite 3 von 14 unverbindliche Hilfestellung in Form von Leitfäden für die Anwendung der EU- Harmonisierungsrichtlinien im Bereich der Medizinprodukte zu geben. [Siehe dazu Quelle 2] Der Leitfaden MEDDEV 2.1/6 beinhaltet Informationen und Beurteilungskriterien, nach denen man eine Einstufung von eigenständiger Software (Stand-alone- Software) als Medizinprodukt gemäß den europäischen Medizinprodukterichtlinien Medical Devices Directive 93/42 EWG (MDD) und In-vitro Diagnostic Directive 98/79/EC (ivdd) vornehmen kann. Dieser Leitfaden enthält zur besseren Visualisierung einen Entscheidungsbaum, der verwendet werden kann, um die Einstufung einer Software als Medizinprodukt bzw. als Nicht-Medizinprodukt durchzuführen und zu begründen. Abbildung 1 gibt diesen Entscheidungsbaum wieder. Abbildung 1: Entscheidungsbaum (Quelle MEDDEV 2.1/6)

4 Seite 4 von 14 Um sich den Inhalt und die notwendigen Schritte zu vergegenwärtigen, ist der Inhalt dieses Entscheidungsbaums in der nachfolgenden Tabelle 1 in Textform enthalten bzw. umgesetzt worden. 1 Stellt die Software ein Computerprogramm dar, z. B. nach ISO/IEC ? 2 Ist die Software Bestandteil eines aktiven Medizinproduktes? 3 Handelt es sich um eine Stand-alone Software? 4 Führt die Software Aktivitäten mit den zu verarbeitenden Daten durch, die nicht über die nachfolgend aufgezählten Datenverarbeitungstätigkeiten hinausgehen? Speicherung Archivierung Verlustfreie Kompression Kommunikation Suche 5 Beziehen sich die Aktivitäten der Software auf einen individuellen Patienten? Wird die Software zum Wohl eines individuellen Patienten eingesetzt? 6 Sind die Aktivitäten für den Einsatz vorgesehen, wie er in Abschnitt 1.2a der Richtlinie MDD definiert ist? Wenn diese Fragen mit ja zu beantworten sind, dann spricht viel dafür, dass die betreffende Software der bzw. den Medizinprodukterichtlinien entspricht. Tabelle 1: Fragen des Entscheidungsbaums MEDDEV 2.1/6 Aus dem MEDDEV-Leitfaden lassen sich deshalb zwei wesentliche Aussagen zur Bewertung einer Software als Medizinprodukt herleiten: Eine Software, die (Roh-)Daten ausschließlich archiviert, abspeichert, durchsucht und/oder Bilddaten ohne Kompression verlustfrei komprimiert, stellt kein Software Medizinprodukt dar. Im Umkehrschluss bedeutet dieses mithin, dass eine Software, die Daten verarbeitet, verändert, zu neuen Ergebnissen verdichtet, Informationen (Empfehlung, Hinweis, Vorschlag, Alarm) ableitet usw., als Software Medizinprodukt angesehen werden könnte. Eine Software muss für einen individuellen Patienten eingesetzt werden. Das bedeutet, dass sie zugeschnitten auf diesen Patienten z. B. Berechnungen, Empfehlungen, Hinweise usw. vornehmen und anzeigen muss.

5 Seite 5 von 14 Diese beiden wesentlichen Aussagen können also bereits als Kriterien zur Bewertung der Medizinprodukte-Funktionen einer Software herangezogen werden. 2. Kriterien zur Bewertung der Medizinprodukte-Funktionen einer Software Die Einstufung einer Software als Medizinprodukt bzw. als Nichtmedizinprodukt kann neben den aufgeführten regulatorischen Dokumenten und dem MEDDEV-Leitfaden vor allem darauf basieren, welche diagnostische und therapeutische Funktionen und Funktionalität eine Software enthält, welche diagnostische und therapeutische Funktionen und Funktionalität in den Unterlagen des Herstellers beschrieben werden, ob ein Nutzer Berechnungen bzw. Algorithmen noch nachvollziehen kann (Nachvollziehbarkeit), wie eine Software mit Rohdaten umgeht, berechnet, verändert und darstellt, welche Qualität der Information eine Software für einen Nutzer erstellt (Empfehlung, allgemeiner Hinweis, Therapiehinweis, Therapievorschlag, Warnhinweis, Alarm), wie zeitkritisch die Berechnungen und daraus resultierende Benachrichtigungen (Alarme) sind, die die Software durchführt, welche unmittelbaren oder mittelbaren Auswirkungen die Funktionalität einer Software auf den physiologischen und/oder pathophysiologischen Zustand eines Patienten ausüben kann (Steuerungsfunktion anderer Medizinprodukte, Steuerung des Behandlungsprozesses, Beeinflussung des Behandlungsprozesses usw.), in welchem Maß eine Software medizinische und pflegerische Prozesse unterstützt, begleitet, abbildet, ermöglicht oder sogar übernimmt, ob sie Gesundheitsparameter bzw. Laborwerte eines individuellen Patienten verarbeitet, korreliert usw., um Empfehlungen, Hinweise, Vorschläge, Alarme und/oder Maßnahmen für diesen Patienten zu erstellen, welchen Automatisierungsgrad eine Software beinhaltet, wie hoch der Komplexitätsgrad ist (Nachvollziehbarkeit, Algorithmen), u. a. Wann aus einem Nicht-Medizinprodukt ein Medizinprodukt werden kann, ist nicht definiert. Vielmehr ist der Übergang fließend. Es gibt bisher auch keine Kriterien, um festzustellen, wann ein Übergang erfolgt. Somit befindet sich die Frage des regulatorischen Übergangs in einer nicht weiter definierten Grauzone, wie es Abbildung 2 verdeutlicht.

6 Seite 6 von 14 Abbildung 2: Grauzone - Übergang von Software als Nicht-Medizinprodukt zum Medizinprodukt Um zu klären, ob eine Software Funktionen bzw. eine Funktionalität aufweist, die der Definition des Medizinproduktes gemäß der Richtlinie entsprechen, kann der folgende beispielhafte Katalog von Bewertungskriterien zu Grunde gelegt werden. Zunächst sollen aber die Begriffe Funktionalität und Funktion, die auch für die Einordnung von Software als Medizinprodukt wesentlich sind, definiert werden. Dies deswegen, weil sehr häufig gefragt wird, ob eine Software Funktionen oder sogar eine Funktionalität aufweist, die der Definition des Medizinproduktes für Diagnostik und Therapie entspricht. 3. Medizinprodukte-Funktion und -Funktionalität einer Software Die Begriffe Funktion und Funktionalität können folgendermaßen definiert werden: Die Funktionalität bezeichnet in der Technik und in der Informatik die Fähigkeit eines Produktes oder einer Komponente, eine bestimmte Funktion oder Gruppe von Funktionen zu erfüllen. [Quelle 3] Als Funktion eines Objektes bezeichnet man die Aufgabe, die es zu erfüllen hat. Die Funktion stellt neben Form, Material, Struktur usw. ein wesentliches Charakteristikum eines jeden Objektes dar, das in irgendeiner Form ge- oder benutzt wird. Die Begriffe Funktionalität und Funktion sollen an einem praktischen Beispiel erläutert und abgegrenzt werden. Jeder kennt Schweizer Taschenmesser. Diese Messer haben nicht nur eine Schneideklinge, die schwerpunktmäßig nur als Messer fungieren soll. Vielmehr beinhalten moderne Schweizer Taschenmesser eine

7 Seite 7 von 14 Vielzahl an anderen Werkzeugen wie z. B. Klingen, Schraubendreher, Feilen, Sägen, Korkenziehern u. a, die jeweils unterschiedliche Einzel-Funktionen erfüllen sollen. Damit hat das Schweizer Messer die Funktionalität als Universalwerkzeug, da es unterschiedliche Werkzeuge enthält, mit denen unterschiedliche Einzel-Funktionen abgebildet werden können. [Quelle 4] Funktionalität einer Software Überträgt man den Begriff der Funktionalität auf Software als Medizinprodukt, so kann man darunter die Fähigkeit verstehen, diagnostische oder therapeutische Tätigkeiten am Menschen durchzuführen. Funktion einer Software Unter Funktion versteht man die Fähigkeit einer Software oder einer abgrenzbaren Software-Komponente, eine bestimmte Aufgabe zu erfüllen. Unter einer Medizinprodukte-Funktion (MP-Funktion) wird deshalb nachfolgend jede Aufgabe/Teilfunktion einer Software verstanden, die den beiden Begriffen Diagnostik und Therapie entsprechen. Dabei wird nicht weiter differenziert in Diagnostische Unterstützung bzw. Therapeutische Unterstützung. Da die Begriffe Diagnose und Therapie für die Einordnung von Software als Medizinprodukt auch von großer Bedeutung sind, sollen sie im Folgenden kurz definiert werden. Definition Diagnose: Schlussfolgerung aus der Symptomkonstellation des Patienten i. S. einer Zuordnung zu bekannten Krankheitsbildern (..) Definition Therapie: Behandlung von Krankheiten, Heilverfahren, umfasst alle medizinischen Maßnahmen, die geeignet sind, Symptome zu lindern u./od. Krankheiten zu heilen. [Quelle 5] 4. Bewertungskriterien In der Praxis trifft man oftmals auf die Schwierigkeit, dass man nicht weiß, nach welchen Kriterien man eine regulatorische Abgrenzung gemäß Abbildung 2 vornehmen kann. Der Verfasser hat in seiner beruflichen Praxis als Sachverständiger für Medizinprodukte die Erfahrung gewonnen, dass es vielfach für eine Einschätzung des regulatorischen Status einer Software sehr sinnvoll ist, Fragen zu stellen und diese zu beantworten. Im Folgenden soll deshalb ein Auszug von Fragestellungen gegeben werden, die dem Verfasser in der Praxis eine Kategorisierung und regulatorische Einstufung einer Software erleichtern. Es empfiehlt sich hierbei, zwischen Funktionalität und/oder Funktionen für einen individuellen Patienten, Grad der Nachvollziehbarkeit, Grad der Informationsqualität,

8 Seite 8 von 14 und Komplexitätsgrad zu unterscheiden. Anforderungen Software zum Einsatz im Gesundheitswesen vorgesehen? Anwendung durch Ärzte vorgesehen? Anwendung durch Pflegekräfte vorgesehen? Software soll eingesetzt werden für: Erkennung von Krankheiten Verhütung von Krankheiten Überwachung von Krankheiten Behandlung von Krankheiten Linderung von Krankheiten Software erfüllt: ja / nein Erkennung von Verletzung oder Behinderungen Überwachung von Verletzungen oder Behinderungen Behandlung von Verletzungen oder Behinderungen Linderung oder Kompensierung von Verletzungen oder Behinderungen Untersuchung des anatomischen Aufbaus oder eines physiologisches Vorgangs Ersetzung oder Veränderung des anatomischen Aufbaus oder eines physiologischen Vorgangs Empfängnisregelung

9 Seite 9 von 14 Informationsqualität Software liefert: allgemeine Aussagen, Empfehlung, allgemeiner Hinweis, Therapiehinweis, Therapievorschlag, Warnhinweis, Alarm Software liefert Aussagen, Empfehlung, allgemeiner Hinweis, Therapiehinweis, Therapievorschlag, Warnhinweis, Alarm für einen individuellen Patienten Software analysiert vorhandene Daten / Informationen, um neue spezifische Informationen gemäß der Zweckbestimmung zu generieren Expertensystem mit Empfehlungscharakter Expertensystem zur Diagnosefindung Expertensystem zur Therapiefindung Werden Therapie- Vorschläge erstellt? Trifft die Software Therapie- Entscheidungen? Kann der Arzt die Berechnungsgrundlage jederzeit nachvollziehen? Kann der Arzt die Berechnungsgrundlage nicht nachvollziehen? Dokumentationssystem in Verbindung mit elektronischen Datenbanken (clinical decision support system: CDSS) Elemente einer elektronischen Patientenakte (EPA) Abbildung medizinischer Prozesse Abbildung pflegerischer Prozesse

10 Seite 10 von 14 Vorgabe und Terminüberwachung von Anordnungen und Pflegemaßnahmen Individuell pro Patient gestaltbarer Pflegebericht oder Arztbericht Dosierungstabellen zur Dosierungsunterstützung (z. b. Dosierung in Abhängigkeit vom Alter und/oder Organfunktion wie Niere o. a.) Übernahme von Daten aus anderen Dokumentations- und/oder Informationssystemen Übernahme von Daten aus anderen Dokumentations-und/oder Informationssystemen mit automatischer Neubewertung und Information bei Erreichen oder Unter-/Überschreiten von Grenzwerten Alarme und Hinweise in Form einer Ampelfunktion mit vorgegebenen oder programmierbaren Grenzwerten Benachrichtigungsfunktion mit vorgegebenen oder programmierbaren Ereignissen Einsatz von Scores Arzneimitteltherapie- Systeme (AMT-System) Weist die Software auf Unverträglichkeiten hin? Hinweise z. B. Medikamenten- Unverträglichkeiten bzw. Kontraindikationen Tabelle 2: Bewertungskriterien Mithilfe einer solchen Bewertungsliste ist es deshalb auch möglich, kompliziertere Fragestellungen zu lösen.

11 Seite 11 von 14 Um sich jedoch vor Augen zu führen, was eigentlich ein Software Medizinprodukt ist, kann es hilfreich sein, zunächst eindeutige Beispiele zu betrachten. So dürfte eine Software, die aus gespeicherten Daten (Vitalparameter, Laborwerte u. a.) eines Patientendatenmanagementsystems (PDMS) als klinisches Informationssystem einen Hinweis oder sogar Alarm bezüglich der sich abzeichnenden Entwicklung einer Sepsis eines individuellen Patienten generiert, eindeutig als Medizinprodukt zu klassifizieren sein. [Quelle 6] 5. Modell der Quantifizierung der Funktion der Medizinprodukte- Funktionen einer Software Da die Betrachtung der Funktionen und Bewertung nicht immer eindeutig eine janein Entscheidung für oder gegen den regulatorischen Status einer Software als Medizinprodukt zulässt, ist es auch möglich, den Grad bzw. die Ausprägung der regulatorischen Funktion bzw. Funktionalität zu quantifizieren. Quantifizierung bedeutet im Prinzip nichts anderes als Angabe von Zahlenwerten, um z. B. die Zuoder Abnahme eines Parameters zu fassen. Mithin werden bei einer Quantifizierung eine oder mehrere Eigenschaften eines Gegenstands oder die Beschaffenheit eines Sachverhalts, in messbare Größen und Zahlenwerte umformuliert. [Quelle 7] Eine solche Vorgehensweise bedeutet, den Grad der Ausprägung einer Medizinprodukte-Funktion oder Funktionalität in einer anschaulichen und nachvollziehbaren Form darzustellen und somit auch zu begründen. Damit kann man vor allem den regulatorischen Übergang einer Software-Funktion/-Funktionalität beschreiben. Der Verfasser schlägt daher folgendes Modell gemäß Tabelle 3 vor, bei dem die Grenze des regulatorischen Übergangs zwischen 1 und 2 definiert wird: Medizinproduktefunktion Nein 0 Minimal 1 Gering 2 Mäßig 3 Stark 4 Vollständig 5 Tabelle 3: Vorschlag zur Quantifizierung mit Übergang des regulatorischen Status einer Software Eine Quantifizierung wird durchgeführt, indem in den Abbildungen 3 und 4 eine numerische Bewertung einzelner Medizinprodukte-Funktionen bzw. der Funktionalität von der entsprechenden Software erstellt wird. Mittels dieser numerischen Quantifizierung von 0 5 sollte zusätzlich eine Beschreibung erfolgen, die den Übergang einzelner Funktionen einer Software in den regulatorischen Status als Medizinprodukt definiert. Wie Abbildung 3 zeigt, sollte diese Tabelle jedoch noch erweitert werden. Es bietet sich bspw. an, in diese Tabelle noch die einzelnen Funktionen einzufügen.

12 Seite 12 von 14 Abbildung 3: Beispiel der Quantifizierung einzelner Funktionen Doch auch die in Abbildung 3 dargestellte Tabelle lässt sich wie Abbildung 4 aufzeigt, noch erweitern bzw. feingranularer gliedern. Hierzu sollten bspw. die Größen Diagnostische und/oder therapeutische Funktionalität für einen individuellen Patienten Grad der Nachvollziehbarkeit Grad der Informationsqualität Komplexitätsgrad Expertensystem ebenfalls in abgestufter Form von 0 5 eingetragen werden.

13 Seite 13 von 14 Abbildung 4: Beispiel der Quantifizierung der Funktionalität 6. Zusammenfassung Nach wie vor bestehen Unsicherheiten, wann und wie eine eigenständige Software als Medizinprodukt einzustufen ist und wie diese Einstufung durchgeführt sowie begründet werden kann. Daher soll die in diesem Beitrag vorgeschlagene Vorgehensweise dem Leser helfen, Antworten auf die Fragestellung zu finden, wann eine Stand-alone Software ein Medizinprodukt darstellt. Neben den regulatorischen Definitionen die oftmals jedoch nicht wirklich zielführend sind - können die zusammengestellten Bewertungskriterien verwendet werden, um die Frage zu beantworten, ob eine Software Medizinprodukte-Funktion bzw. eine Medizinproduktefunktionalität aufweist, auf Grund derer die Software als Medizinprodukt klassifiziert werden kann. Weiterhin ist es möglich - aufgrund der individuell anpassbaren Quantifizierung - den schwer fassbaren Grad der diagnostischen und/oder therapeutischen Ausprägung einer Medizinprodukte-Funktion und auch Funktionalität anschaulich darzustellen. Die hieraus gezogenen Erkenntnisse können zusätzlich neben den sonstigen Bewertungskriterien als Grundlage zur regulatorischen Beurteilung verwendet werden. In einem weiteren Beitrag soll diese Methodik am Beispiel von Arzneimitteltherapie- Systemen diskutiert werden.

14 Seite 14 von 14 Literatur und Quellenangaben 1. MEDDEV 2.1/6 letzter Zugriff Gärtner. A.; MEDDEV-Leitfaden 2.1/6 für Software als Medizinprodukt am Beispiel PDMS, Loseblattwerk Medizintechnik + Informationstechnologie = MIT, Verlag TÜV Media Köln, ISBN letzter Zugriff letzter Zugriff Pschyrembel: Klinisches Wörterbuch 2011, Verlag De Gruyter 6. Wider die Skepsis bei der Sepsis; Drägerwerk AG, Krankenhaus Technik- Management 7-8/2014, S letzter Zugriff Anschrift des Verfassers Armin Gärtner Ingenieurbüro für Medizintechnik Ö. b. u. v. Sachverständiger für Medizintechnik Edith-Stein-Weg Erkrath armin.gaertner@t-online.de