gms | German Medical Science

GMS Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS)

ISSN 1860-9171

Risiken und Nebenwirkungen der Integration medizinischer Software in klinische IT-Strukturen – Erlanger Memorandum

Software as a medical device – side effects when applying the new European regulation on medical devices for IT products

Übersichtsarbeit

  • corresponding author J. Kaiser - Universitätsklinikum Erlangen, Deutschland
  • author U.M. Gassner - Universität Augsburg, Forschungsstelle für Medizinprodukterecht, Augsburg, Deutschland
  • author M. Reng - MedicDat GmbH & Med. Fakultät der Univ. Regensburg, Deutschland
  • author H.U. Prokosch - Universität Erlangen-Nürnberg, Lehrstuhl für medizinische Informatik, Erlangen, Deutschland
  • author T. Bürkle - Universität Erlangen-Nürnberg, Lehrstuhl für medizinische Informatik, Erlangen, Deutschland

GMS Med Inform Biom Epidemiol 2012;8(1):Doc03

doi: 10.3205/mibe000127, urn:nbn:de:0183-mibe0001273

Veröffentlicht: 12. Dezember 2012

© 2012 Kaiser et al.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.de). Er darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Zusammenfassung

Durch die Änderung der Medizingeräterichtlinie auf europäischer Ebene kann nun auch eigenständige medizinische Software zum Medizinprodukt werden, wenn sie zur medizinische Diagnostik oder Therapie eingesetzt wird. Sukzessive werden diese Vorgaben seitens der EU-Mitgliedstaaten in nationales Recht implementiert, beispielsweise in das deutsche Medizinproduktrecht.

Für einige Systeme aus der angewandten medizinischen Informatik, beispielsweise für Picture Archiving and Communication Systeme (PACS) ist diese Einordnung als Medizinprodukt – zumindest teilweise – bereits etabliert. Für die üblichen patientenführenden Systeme wie Patientendatenmanagementsysteme (PDMS), Klinische Arbeitsplatzsysteme (KAS) und Laborinformationssysteme (LIS) bedeutet dies jedoch eine neue Entwicklung.

Diese Arbeit behandelt die Umstände, unter denen ein PDMS auf einer Intensivstation, ein KAS oder ein LIS als Medizinprodukt eingeordnet werden kann und die sich daraus ergebenden Konsequenzen. Dies kann ggf. schon der Fall sein, wenn das genannte System Laborwerte, Vitalwerte und Behandlungsdaten in einer intelligenten Sicht, verbunden mit Therapieratschlägen darstellt und damit Diagnostik und Therapie unterstützt.

Vom Anwender wird heute berechtigterweise gefordert, dass moderne klinische Informationssysteme wie PDMS und KAS ihn mit medizinischen Informationen und wissensbasierten Funktionen (Entscheidungsunterstützung und Entscheidungsmonitoring) bei seiner Arbeit unterstützen. Juristisch gesehen folgt hieraus, dass solche Systeme unabhängig von der Herstellerklassifikation als de facto relevant für medizinische Diagnostik oder Therapie eingeordnet werden, womit sie unter das Medizinproduktrecht fallen. Das Medizinproduktrecht unterscheidet die Medizinprodukte-Klassen: I (niedriges Risiko), II und III (hohes potentielles Patientenrisiko). Sollte beispielsweise ein in der Intensivmedizin eingesetztes PDMS Vitaldaten des Patienten prüfen, um ergänzend zum Monitor-System ggf. Warnhinweise zu generieren (z.B. bei Blutdruckabfall und Hypoglykämie), dann würde dieses PDMS oder zumindest das entscheidungsunterstützende Modul eventuell in der gleichen Hochrisikogruppe II landen, in der auch Infusionspumpen eingruppiert sind. Es ergeben sich dann massive Konsequenzen im Hinblick auf Design und Betrieb eines solchen Systems. Die neuen Richtlinien könnten ebenfalls bewirken, dass die Kliniken als Betreiber von Medizinprodukten sich plötzlich in einer Herstellerverantwortung sehen, wenn sie innerhalb der Klinik eigene Entscheidungsregeln im System definieren, die zu Hinweisen und Warnungen führen. Im vorliegenden Beitrag diskutieren die Autoren die Auswirkungen der Neuregelung und legen die Schwierigkeiten und unerwünschte Effekte offen, die für Hersteller als auch für Betreiber kaum beherrschbar sind, wenn die neuen Regeln kompromisslos umgesetzt werden.

Abstract

European medical device regulations have been altered to cover pure software applications as well. They now may be classified as a medical device if used for medical diagnostics and/or medical treatment. Slowly, these regulations are being implemented into national law of the EEC member states, for example into the German MPG (Medical Product Law).

For some software applications such as Picture Archiving and Communication systems (PACS) a classification as medical device is – at least for parts of it – routine today, ruling e.g. the quality of medical monitor screens for assessment of x-ray pictures. For software applications such as patient data management systems (PDMS), electronic health records (EHR), laboratory information systems and similar systems this was not the case so far.

This paper deals with the consequences which may arise if a PDMS used on intensive care units or even an EHR is now classified as a medical device, e.g. because it is able to deliver intelligent composite views on laboratory data, medical data, and treatment information to support diagnostic assessment or treatment advice.

Modern clinical information systems, PDMS and EHR support the user with medical information and clinical decision support (CDSS). So there is doubt that they are used for diagnostics and/or treatment. Medical device regulations distinguish between medical product classes I (low risk), II and III (high risk) of medical devices according to potential risks for the patient. IF CDSS functions e.g. as modules of a PDMS use vital sign values in the decision algorithms, the PDMS may even be classified as class II medical product, similar to e.g. intravenous pumps. If decision rules of a decision support-system are defined by IT-administrators working for a hospital itself it could even become manufacturer of the medical device.

The authors discuss implications and demonstrate difficulties which arise for manufacturers as well as for hospitals or the users of medical software if the new regulation is strictly enforced.


Einleitung

Noch immer verunsichert die Novelle des Medizinproduktegesetzes (MPG) vom 21. März 2010 Hersteller und Betreiber medizinischer Informationssysteme, da sie auch medizinische Software zum eigenständigen, aktiven Medizinprodukt erklärt. Die Novellierung des Gesetzes kam nicht unvorbereitet, wurde doch in den vergangenen Jahren immer wieder vereinzelt über die geplanten Neuerungen gesprochen. Jedoch wurden weitestgehend nur Hersteller informiert und auf die neuen Regelungen hingewiesen. Nur wenige Krankenhäuser haben bisher die Änderungen intensiv reflektiert oder Maßnahmen ergriffen.

Vor diesem Hintergrund fand 2011 am Lehrstuhl für Medizinische Informatik der FAU Erlangen-Nürnberg ein Workshop „KAS und PDMS als IT- oder Medizinprodukt“ mit einem Erfahrungsaustausch zwischen Firmenvertretern, Juristen, Medizininformatikern, Klinikrechenzentrumsleitern, Medizinproduktebeauftragten und Ärzten statt. Während KAS im nachfolgenden Kontext für das klinische Arbeitsplatzsystem steht, welches auf Normalstationen und in Ambulanzen eines Krankenhauses die Prozesse unterstützt und die medizinische und pflegerische Dokumentation ermöglicht, steht PDMS für das Patienten-Daten-Management-System welches äquivalent zum KAS auf Intensivstationen zum Einsatz kommt und oft auch den Narkosearbeitsplatz im OP mit einschließt. Ein PDMS kommt in der Regel mit enger Anbindung an Medizingeräte zur automatisierten Übernahme beispielsweise von Daten des Patientenmonitors oder des Beatmungsgerätes zum Einsatz. Eine klare Aussage des Workshops war, dass unter den neuen regulatorischen Bedingungen ein KAS oder PDMS bzw. Module derselben mit Funktionen zur Entscheidungsunterstützung als Medizinprodukt betrachtet werden muss, selbst wenn es weder technisch, noch inhaltlich nachträglich als Medizinprodukt geplant und daher kaum zertifizierbar ist.


Regulatorischer Rahmen

Die Herstellung, der Betrieb und die Anwendung von Medizinprodukten bergen Risiken und werden deshalb durch das MPG und die auf ihm beruhenden Rechtsverordnungen reguliert. Sie werden mit EG Regelungen synchronisiert (für die internationale Situation siehe auch [1]) und zielen darauf ab, gerade auch bei der Anwendung von Medizinprodukten die damit möglicherweise verbundene Patientengefährdung zu vermeiden. Deshalb verlangt die Medizinprodukte-Betreiberverordnung [2], dass Medizinprodukte nur ihrer Zweckbestimmung entsprechend und nach den Vorschriften dieser Verordnung, den allgemein anerkannten Regeln der Technik sowie den Arbeitsschutz- und Unfallverhütungsvorschriften errichtet, betrieben, angewendet und in Stand gehalten werden dürfen.

Die „allgemeinen Regeln der Technik“ umfassen hierbei alle geschriebenen und ungeschriebenen Regeln, die Fachleuten nach neuester Ausbildung durchgängig bekannt sind bzw. sein müssten. Dazu gehören die Eckdaten der wesentlichen Sicherheitsvorschriften und Vorgehensweisen, die durch zahlreiche weitere Normen definiert werden.

„Zweckbestimmung“ ist die Verwendung, für die das Medizinprodukt in der Kennzeichnung, der Gebrauchsanweisung oder den Werbematerialien nach den Angaben des Herstellers bestimmt ist [3]. Maßgeblich hierfür ist also der bestimmungsgemäße Gebrauch, wie ihn der Hersteller vorsieht. Dies macht es erforderlich, dass Software, die im medizinischen Bereich eingesetzt wird, eine klar umrissene Zweckbestimmung besitzt. Betreiber und Anwender müssen dieser Zweckbestimmung folgen, sonst tragen sie für Schäden, die jenseits des bestimmungsgemäßen Einsatzzwecks entstehen, die volle Haftung.

Bisher war die Welt der Software im Gesundheitswesen recht ‚einfach‘, denn viele EDV-Anwendungen in Kliniken galten als „reine IT-Systeme“ ohne (Medizin-)Geräteanbindung, über die der regulatorische Rahmen der Medizinprodukte bis 21.3.2010 nicht gespannt war. „Nur-Software“ war zwar im Interesse des Herstellers sorgfältig herzustellen, ein regulatorischer Rahmen, der den Herstellungs-, Test- und Dokumentationsprozess vorsah, existierte nicht. Erst durch die Änderungsrichtlinie 2007/47/EG erfolgte eine „Klarstellung“ bzw. Revision der Medizingeräterichtlinie MDD der EU vom September 2007 [4], wodurch auch die Herstellung solcher Software dezidiert unter die gleichen technischen Vorgaben wie medizintechnische Systeme gestellt wird. Daraus resultiert auch die Notwendigkeit zur Qualitätssicherung, zum Risikomanagement und zur Dokumentation bei Hersteller und Betreiber.


Patientengefährdung

Dass Softwarekomponenten in Medizinprodukten zu Patientengefährdung führen können, ist nicht zu leugnen. Als Beispiel kann ein Fall von durch eine problematische und nicht intuitive CT-Steuerungssoftware in Verbindung mit zusätzlichen Bedienerfehlern verstrahlten US-Patienten in Los Angeles und Huntsville genannt werden [5]. In diesem Falle handelte es sich allerdings um Gerätesteuerungs-Software zur automatisierten Festlegung der CT-Scanintensitäten, die seit jeher der Medizinproduktregulierung sowohl der USA als auch der Europäischen Union unterliegt. Dennoch konnte es zu dieser Schädigung kommen.

Bei vielen im Krankenhaus eingesetzten Informationssystemen ist der Übergang zwischen reinen Dokumentationsfunktionen, z.B. für die Abrechnung, Qualitätssicherung oder zur Archivierung im Sinne der Dokumentationspflicht und Funktionen zur Unterstützung von diagnostischen oder therapeutischen Aktivitäten der Ärzte fließend. Der Europäische Rat definierte bereits in seiner Richtlinie 93/42/EWG Software als Medizinprodukt, wenn diese die für den Zweck der „Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten“ bestimmt ist.

Durch die Meddev 2.1/6 [6] wird weiter spezifiziert, dass reine Dokumentations-, Kommunikations- und Datenbanksoftware nicht als Medizinprodukt zu betrachten ist und dass Software, die nicht für individuelle Patienten, sondern für statistische Auswertungen eingesetzt wird, ausgenommen ist.

Ob der Einsatz einer Software dem Zweck der Diagnostik oder Therapie dient und damit der Medizinprodukteregelung unterliegt [7], kann allerdings nur bedingt aus der Produktgruppe (z.B. KAS, RIS, LIS, PDMS) gefolgert werden, da unter diesen Begriffen Softwareprodukte mit sehr unterschiedlicher Funktionalität auf dem Markt angeboten werden. Bei jedem in einem medizinischen Umfeld eingesetzten Softwaresystem, das in seiner Zweckbestimmung in den Definitionsrahmen für Medizinprodukte im Rahmen der MDD fällt, muss der Hersteller daher unabhängig von der Produktbezeichnung verifizieren, welche Funktionalitäten die Software beinhaltet oder ggf. auch erst nach einer Parametrierung durch den Nutzer enthalten kann. Weiterhin muss die Funktionalität eines derartigen Systems vom Hersteller eindeutig definiert werden und das System mit einer Zweckbestimmung im Sinne des Medizinproduktegesetz ausgestattet werden. Dann muss die entscheidende Frage geklärt werden, wie groß das entsprechende Patientengefährdungsrisiko ist, und in welche Medizinproduktklasse dieses System eingestuft werden muss.


Neuerungen 2010 und 2011 fordern Hersteller und Kliniken

Die maßgebliche Neuerung, die durch die Richtlinie 2007/47/EG [MDD_07] eingeführt wird behandelt den Aspekt der eigenständige Software, die fortan als aktives Medizinprodukt gilt.

Dies stellt eine Abkehr von der bisherigen Sichtweise dar, bei der vor allem Software betroffen war, die, oftmals in einer maschinennahen Sprache geschrieben, ein integraler Bestandteil eines Medizingeräts war, und demnach als eine Art Betriebssoftware funktionierte. In der klinischen Anwendung gibt es aber natürlich schon lange „Stand-Alone“- Software im Einsatz für den Patienten ohne physischen, d.h. direkten Patientenkontakt. Solche Softwaremedizinprodukte unterscheiden sich maßgeblich von der vorgenannten hardware- und patientennahen (Medizinproduktsoftware) Gattung [8]. Die „Klarstellung“ der EU hat zudem erschwerend die EN 62304 [9] im Schlepptau, die das Software-Lebenszyklusmodell für Medizinproduktsoftware und damit auch für alle eigenständigen Softwaremedizinprodukte verbindlich macht.

Die beiden Typen von Ausprägungen, also Betriebssoftware für Medizingeräte und medizinische Software, werden vom Gesetzgeber fortan gleich behandelt, obwohl sie im klinischen Bereich unterschiedlich eingesetzt werden und ihre jeweiligen Stärken nur dort entwickeln können: Medizinproduktsoftware wird oft innerhalb eines weitgehend geschlossenen Systems angewendet (z.B. Steuerung eines CT-Gerätes), während Softwaremedizinprodukte (z.B. KAS, PDMS) als Einzelplatzlösungen, wie auch als offene Systeme mit Kommunikation zu einer Vielzahl anderer EDV-Systemen, von denen Daten übernommen oder an die Daten geliefert werden, betrieben werden.

Dieses „offene Modell“ beinhaltet einen weiteren wichtigen Aspekt: Nicht wenige Softwaresysteme, die unter die Regulierung der MDD fallen, werden vom Hersteller als parametrierbare bzw. konfigurierbare EDV-Systeme ausgeliefert, die erst vom Anwender mittels Parametrierung von Dialogen und Funktionalitäten auf den lokalen Einsatz angepasst werden. Dies führt dazu, dass beispielsweise dasselbe PDMS in zwei verschiedenen Krankenhäusern, ja möglicherweise sogar im selben Krankenhaus auf zwei verschiedenen Stationen eine völlig unterschiedliche und vom Hersteller auch nicht kontrollierbare, ggfls. nicht einmal vorhersehbare Konfiguration, und damit möglicherweise auch eine unterschiedliche Zweckbestimmung aufweist. Sofern davon Funktionen zur Diagnostik oder Therapie individueller Patienten betroffen sind, beispielsweise wissensbasierte Warnhinweise oder ähnliches, die ja der Diagnostik oder Therapie dienen, muss zumindest dieser Teil als Medizinprodukt zertifiziert werden. Dabei bleibt aber für den Betreiber offen, wo in dieser Situation der Übergang zwischen dem bestimmungsgemäßen Betrieb eines Medizinproduktes und der Erstellung bzw. Veränderung desselben Medizinproduktes (durch Parametrierung) liegt. Wird nun also der Anwender (z.B. das diese Software betreibende Krankenhaus, der die Änderungen vornehmende Informatiker oder der die Inhalte definierende Arzt) durch Parametrierung zum „Hersteller“ oder bleibt die Herstellerverantwortung bei dem, der das Softwaresystem in der parametrierbaren Form ausgeliefert hat?

Durch die Einordnung der IT-Systeme als Medizinprodukt ist die bisherige flexible Handhabung jeglicher Parametrierung gefährdet, die Medizinproduktebetreiberverordnung [10] sieht hierfür keine verbindliche Regelung vor.

Beispiel

Ein „reines Dokumentationssystem“ für die Medizin erlaubt es, mit Hilfe seiner Parametrierung patientenindividuelle, einfache Berechnungen durchzuführen. Eine Klinik nutzt diese Funktion, um aus mehreren klinischen Parametern einen Score zu berechnen, der eine Prognose über den weiteren klinischen Verlauf zulässt. Neben zahlreichen anderen Parametern wird auch dieser Score dazu herangezogen, den Arzt bei der Steuerung des Behandlungsverlaufs zu unterstützen. Per Definition ist der Score damit an der „Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten“ beteiligt. Das Dokumentationssystem oder das entsprechende Modul wird so unzweifelhaft zum „aktiven Medizinprodukt“. Sogar der klinisch regelhaft erfolgende Rückgriff auf Daten der Patientenhistorie kann eine „Beeinflussung des Behandlungsverlaufes“ zur Folge haben, so wird strenggenommen durch die entsprechende Nutzung auch aus einem Dokumentations- und Archivierungssystem ein Medizinprodukt.

Auch wenn es sich bei der Novelle der Richtlinie 93/42/EWG [11] durch die Richtlinie 2007/47/EG beim entscheidenden Aspekt des Softwaremedizinprodukts in der Sprachregelung der EU nur um eine Klarstellung handelt, so wird diese „Klarstellung“ ihrem Namen nicht wirklich gerecht. So musste das Thema durch die Meddev 2.1/6 eingehender behandelt werden.

Klar ist die Einordnung von PAC-Systemen in der neuen Medizingerätedefinition, da hierzu bereits im aktuellen Manual zu „borderline and classification… for medical devices“ der EU [12] Aussagen gemacht werden: Ein PACS, das Bildmanipulationen zu diagnostischen Zwecken zulässt (Ausmessung, Filterung etc.), ist ein Medizingerät. Die Implikationen für alle nicht zur unmittelbaren Befundung vorgesehenen, aber durchaus zur Bildmanipulation (Vergrößerung, Kontrastierung, Helligkeitsänderung) befähigten PACS-Clients auf den Stationen der europäischen Krankenhäuser sind nicht abzusehen.

Die Meddev 2.1/6 beinhaltet einem Kriterienkatalog für verschiedene Gruppen anderer medizinischer Softwaresysteme wie KIS, KAS, RIS, PACS, PDMS, der die Risiken einer potentiellen Patientengefährdung bewertet und eine grundsätzliche Empfehlung im Hinblick auf die Einordnung als Medizinprodukt beinhaltet. Es finden sich demnach generelle Aussagen (Ein „KIS“ ist zunächst kein Medizinprodukt), die durch Einschränkungen (Ein PDMS oder seine Module werden Medizinprodukt, wenn sie zusätzliche Informationen anbieten, die der Diagnostik, Therapie oder Nachsorge dienen) relativiert werden.


Klassifizierung als Innovationshindernis

Neben der Tatsache, dass ein Softwareprodukt überhaupt als Medizinprodukt klassifiziert werden muss, ist für den damit verbundenen Aufwand aber fast noch wichtiger, welcher Medizingeräteklasse das Softwareprodukt dabei zugeordnet wird. Die Regularien in Bezug auf Entwicklung, Schulung und Betrieb einer Software der Medizinproduktklasse I unterscheiden sich drastisch von denen für Software einer höheren Geräteklasse.

Risikoklassifizierung entsprechend Anhang IX der Richtlinie 93/42/EWG

  • Klasse I – Keine methodische Risiken, geringer Invasivitätsgrad
  • Klasse IIa – Anwendungsrisiko, mäßiger Invasivitätsgrad
  • Klasse IIb – Erhöhtes methodisches Risiko, systemische Wirkungen, Langzeitanwendungen
  • Klasse III – hohes Gefahrenpotential

Während Entwurfsversionen der Meddev 2.1/6 noch eine Vielzahl von Standalone-Softwaremedizinprodukten in dieselbe hohe Klasse IIb, d.h. wie ein Patientenmonitoringsystem einordneten, so wurde dies in der freigegebenen Version glücklicherweise auf diejenigen Module begrenzt, die für die Steuerung derjenigen Vorgänge zuständig, bei denen Energie auf Patienten einwirkt. Generell ist allerdings davon auszugehen, dass jegliches Standalone-Softwaremedizinprodukt, welches Steuerung invasiver diagnostischer oder therapeutischer Maßnahmen beeinflusst, so zu gruppieren ist, wie eine entsprechende Medizinproduktsoftware. Dies gilt beispielsweise für Warnhinweise in einem PDMS bei kritischen Vitaldatenwerten, unabhängig davon, ob andere, teilweise sogar redundante Systeme (z.B. das Patientenmonitoringsystem) den Patienten zusätzlich überwachen, ob in diesen anderen Systemen auch Schwellwertgrenzen der Alarme definiert sind, oder ob im Workflow der behandelnden Station Fail-Safes implementiert sind. Für die Einordnung als Medizinprodukt der Klasse IIb genügt laut Angang IX der MDD hierbei die sog. „direkte Diagnose von Vitaldaten“, d.h. die direkte Ableitung einer Diagnose vom angezeigten Inhalt.

Die Einstufung einer Software als Medizinprodukt kann für Hersteller und Betreiber erhebliche Auswirkungen haben. Zunächst sind das Aufwand und Kosten. Die MPV [13] erfordert an dieser Stelle eine Qualitätssicherung welche Parametrierungen und Konfigurationsänderungen überprüft und dokumentiert, sowie die Durchführung eines Risikomanagements. Aufwand und Kosten hierfür steigen mit der Eingruppierung in jede höhere Medizinproduktklasse deutlich an. Besonders betroffen sind innovative, integrative Software-Komponenten mit Schnittstellen zu mehreren medizinischen Systemen und Auswertungslogiken, Berechnungsfunktionen sowie Assoziativkomponenten zu klinischen Leitlinien oder Behandlungspfaden. Solche Komponenten, die heutzutage zunehmend als Mehrwert von Softwaremedizinprodukten gefordert werden, und sowohl Effizienz als auch Effektivität medizinischer Leistungen verbessern sollen, werden dazu beitragen, dass ein System oder das entsprechende Modul, das bis vor kurzem noch als „Nur-IT-Produkt“ galt, möglicherweise durch die Einordnung als Medizinprodukt dann nicht in die moderate Klasse I, sondern in die Klasse IIa oder gar IIb eingeordnet werden muss und damit das Risiko besteht, dass Entwicklung und Betrieb eines solchen Systems für Hersteller und Nutzer nicht mehr wirtschaftlich sind. Dies könnte sich schlussendlich zum Abbruch der Softwareentwicklung und damit zum Nachteil für den Patienten auswirken.

Die in jedem Fall erwachsende Konsequenz ist, dass Produktinnovationen im Medizinbereich vom Hersteller in Zukunft deutlich aufwendiger dokumentiert werden müssen und die Kosten für Neuerungen gerade im Bereich der intelligenten Datenverarbeitung drastisch in die Höhe getrieben werden. Alternativ ist zu vermuten, dass sich viele Hersteller aus Kostengründen bei den Systemen auf die Basisfunktionalitäten des Speicherns und Archivierens beschränken und derartige „intelligente“ Module nicht mehr anbieten. Schlimmstenfalls folgt daraus, dass wir Software-Produkte bzw. entsprechende Produktfunktionalitäten, die bisher den Ablauf und die Patientensicherheit in Kliniken deutlich verbessert haben bzw. verbessern sollten nicht weiter verwenden bzw. gar nicht erst bekommen werden.

Momentan werden solche Funktionalitäten beispielsweise angestrebt, um neben dem reinen Datenmanagement auch die Einhaltung von Behandlungspfaden zu unterstützen, oder um dem Arzt im Krankenhaus zeitnah per Pager oder DECT-Handy Informationen über Werte von kritisch kranken Patienten zu geben. Letztlich fallen aber kritisch betrachtet alle zusätzlich zur klinischen Routine eingesetzten Werkzeuge, die im Rahmen der Qualitätssicherung eingesetzt werden und eine Diagnose- oder Therapiefunktion im Rahmen der Zweckbestimmung haben könnten, unter diese neue Regelung.

Nach der Meddev 2.1/6 ist davon auszugehen, dass Systeme oder Module, die Patientendaten in der vorgenannten Form ergänzend überwachen oder zeitnah Alarme erzeugen können, unabhängig vom Vorhalten weiterer Systeme mit ähnlicher Funktionalität, als potenziell patientengefährdend betrachtet und als Medizinprodukt in die Klasse IIa eingestuft werden müssen. Es ist an dieser Stelle auch irrelevant, ob der Patient auf einer Intensivstation liegt und dort parallel zusätzlich rund um die Uhr durch Intensivpfleger und Ärzte betreut wird, so dass die genannten Funktionen eigentlich nur einen Mehrwert im Sinne der Qualitätssicherung und Fehlerkontrolle darstellen. Vielmehr wird davon ausgegangen, dass unter Anwendung die vorgenannten Funktionen durch ihre Option, die Patientenversorgung zu beeinflussen, prinzipiell zur Grundlage derselben gehören und dass deren Fehlfunktion oder Ausfall damit kritische Folgen haben können.

Diese Vorgehensweise, sich ohne Betrachtung des Gesamtkontexts auf das einzelne Produkt zu konzentrieren, erweist sich für die Ausgestaltung von sicherheitsrelevanten Prozessen auf Intensivstationen als hinderlich für jegliche Softwareinnovation. Gerade beim Aufbau von Intensivstationen gibt es keine starren Vorgaben, sondern es wird lediglich der sogenannte Stand der Kunst erwartet.

Führende Medizininformatiker und Ärzte betonen seit Jahrzehnten: „medical decision support functions support the physician and never replace him or his final intellectual decision [14]“. Diese Überlegungen werden in der Meddev 2.1/6 nicht gewürdigt.


Die Herstellerklassifikation löst das Problem aktuell noch nicht vollständig

Derzeit sind die überwiegende Zahl klinischer Informationssysteme wie KAS, RIS, LIS oder PDMS und andere in der Medizin genutzte Softwareprodukte vom Hersteller entweder überhaupt nicht oder im Falle von PDMS vereinzelt in der niedrigen MPG Klasse I deklariert. Dabei wird argumentiert, dass die Systeme als reines Archivierungs- oder Dokumentationswerkzeug einzusetzen sind, und nicht für Diagnostik und Therapie verwendet werden dürfen. Dennoch beinhalten derartige Systeme häufig Funktionen wie das Zusammenführen verschiedener Patientendaten an einer Stelle, um beispielsweise schnell einen kumulierten Überblick über Organfunktionen oder den klinischen Gesamtverlauf zu gewinnen, ggf. stellen sie auch wissensbasierte Funktionen zur ärztlichen Entscheidungsunterstützung und zum Entscheidungsmonitoring bereit. Sind diese Systeme nicht für Diagnostik und Therapie vorgesehen, so übernimmt in bestimmten Situationen der Anwender/Betreiber ebenfalls die Herstellerrolle und macht sich damit unter Umständen strafbar, was weder im Sinne der Hersteller, noch im Sinne der Nutzer und noch weniger im Sinne von Patienten und Regulierungsbehörden sein kann.

Beispiel: Befundung mit nicht befundungsfähigen Monitoren

Bei der Nutzung von Bildern mit einem PACS (Picture Archiving and Communication System) im klinischen Zusammenhang wird technisch zwischen Befundung und Nicht-Befundung (=Illustration eines an anderer Stelle erhobenen Befundes) unterschieden. Dementsprechend werden Programme als Medizinprodukt oder nicht klassifiziert. Befundet werden darf natürlich nur an für die Befundung zugelassenen Monitoren, die an einem geeigneten Platz aufgestellt wurden. Befundungsfähige Monitore müssen zudem bestimmten Eigenschaften (definiert durch die Röntgenverordnung RöV) genügen. In medizinischen Arbeitsabläufen wird darauf oft wenig Rücksicht genommen. So werden in der Praxis gelegentlich auch Monitore, die offiziell nicht zur Befundung zugelassen sind, zur Befundung eingesetzt.

Mit Recht greift ein Arzt (bei gleichzeitiger Bewertung der Validität der Informationsquelle) bei der akut erforderlichen Beurteilung eines Patienten auf alle Informationen zurück, derer er in der momentanen Situation habhaft werden kann. Ein Bild ist besser als kein Bild und in Notfallsituationen kann der Weg zum nächsten „zugelassenen“ Monitor oft schon zu weit sein.

Problematisch ist in diesem Zusammenhang die Vorgehensweise mancher Hersteller, die in ihren Unterlagen diagnoserelevante Funktionen sowohl an zur Befundung zugelassen Stationen als auch an nicht zur Befundung zugelassenen anbieten. Derartige Funktionen der Software werden oftmals innerhalb der Werbematerialien propagiert und zugleich technisch zur Verfügung gestellt, aber wiederum innerhalb der Gebrauchsanweisung dann relativiert, indem sie verboten werden. Die „verbotenen“ Funktionen werden dann an den nicht für die Befundung qualifizierten Arbeitsplätzen nicht deaktiviert – dies wird dem Betreiber „überlassen“. Im Falle einer Haftungssituation, auch durch einen Programmfehler des Herstellers, obliegt die Verantwortung für die irreguläre Nutzung der Programmfunktionen in diesem Fall alleine dem Anwender.

Bisherige Beispiele zeigen, dass viele Hersteller auch über zwei Jahre nach Inkrafttreten der 4. Novelle des MPG noch nach der Devise „Abwarten und Teetrinken“ agieren [15]. In zurückliegenden Publikationen sprechen Firmenvertreter z.B. davon, dass sie „ein Arzneiverordnungsmodul als Produkt im Portfolio haben, für das die Frage der Interpretation des 4. Novelle des MPG irgendwann einmal relevant werden könnte“. Betrachtet man im Vergleich die Marketingaussagen zum selben Produkt, z.B. „Wir haben für Sie SystemX® entwickelt – die elektronische Verordnungsunterstützung zur Optimierung von Sicherheit und Kosteneffizienz der medikamentösen Therapie“ (Zitat unter Abwandlung des Systemnamens entnommen von der Homepage eines Anbieters), so ist die juristische Sachlage aber eigentlich klar und ein Herausreden auf „Graubereiche“ unangebracht.


Verantwortung des Betreibers auch bei Fehlklassifizierung

Das im vorherigen Abschnitt beschriebene Problem der absichtlichen oder unabsichtlichen Fehlklassifizierung darf nicht auf die leichte Schulter genommen werden, denn der Betreiber ist hierbei keineswegs durch Aussagen des Herstellers komplett aus der Verantwortung entlassen. Selbst wenn eine Software oder ein Modul vom Hersteller (noch) nicht als Medizinprodukt klassifiziert ist, so ist letztendlich doch entscheidend, in welcher Form und zu welchem Zweck diese von den Mitarbeitern eines Krankenhauses eingesetzt wird. Die Schutzbehauptung, dass eine Software, bei der Inhalte der elektronischen Krankenakte für bestimmte medizinische Fragestellungen gezielt gefiltert und die dazu relevanten Befunde aus unterschiedlichen Abteilungssystemen an einer Stelle intelligent zusammengeführt und interpretiert werden, von den ärztlichen Nutzern dieses Systems nicht zur Unterstützung ihrer diagnostischen und therapeutischen Aktivitäten genutzt würde, kann im Falle einer juristischen Auseinandersetzung schnell ausgehebelt werden. Zuletzt wird dies immer dann passieren, wenn echte Behandlungsfehler erfolgt sind und der Behandelnde seinen Fehler zu rechtfertigen versucht („wenn ich zu diesem Zeitpunkt gewusst hätte, dass der Befund XY vorlag, hätte ich mich anders verhalten. Der Softwarefilter hatte diesen Befund aber ausgeblendet, d.h. die Software ist schuld“).

Bei anderweitiger oder erweiterter Verwendung eines Medizinprodukts am bestimmungsgemäßen Gebrauch vorbei, obliegt dem Betreiber im Schadensfall die Verantwortung.

Fazit müsste eigentlich sein, dass derartige Softwaremodule, auch wenn sie „irrtümlich“ durch den Hersteller nicht als Medizinprodukt in Verkehr gebracht wurden, dennoch als solches durch Kliniken und Arztpraxen zu betreiben sind, sobald die entsprechende Funktionalität eindeutig für diagnostische oder therapeutische Zwecke angewendet wird. Diese Ansicht wird gegenwärtig durch Fachleute oft in Frage gestellt, da Software in diesem Zusammenhang nicht speziell in den relevanten Anhängen 1 oder 2 der Betreiberverordnung aufgeführt ist. Krankenhäuser sollten sich aber keinesfalls auf der sicheren Seite wähnen, da Gerichte durch eine unionsrechtskonforme Auslegung des Sachverhalts zu einem anderen Schluss kommen könnten: Auch Software, die vom Hersteller nicht als Medizinprodukt in Verkehr gebracht wurde, kann im Krankenhaus jedenfalls unter haftungsrechtlichen Gesichtspunkten zum Medizinprodukt werden, wenn sie zu Diagnostik oder Therapie eingesetzt wird [16].

Ein weiterer kritischer Punkt bei Betrieb eines Medizinproduktes ist die Verpflichtung zur Marktbeobachtung im Rahmen der Vigilanzvorschriften, die dem Hersteller und Betreiber (!) obliegen: Auch der Betreiber muss also am Markt verfügbare Software mit ähnlicher Funktionalität systematisch beobachten um etwaige Gefährdungen für Patienten durch diese Softwareklasse rechtzeitig zu erkennen und in das Risikomanagement der von ihm betriebenen Software einfließen zu lassen. (Die Vigilanz im Rahmen von Medizinprodukten wird in Deutschland durch die „Verordnung über die Erfassung, Bewertung und Abwehr von Risiken bei Medizinprodukten“ (MPSV) geregelt.)


IT-Abteilung wird zum Medizinproduktbetreiber

Als Quintessenz der Diskussion folgt, dass die IT-Abteilung einer Klinik künftig zum Betreiber von zahlreichen Medizinprodukten oder -Modulen wird und diese Rolle in Aufbau- und Ablauforganisation wahrnehmen muss. Das juristische Risiko im Schadensfall ist klar definiert und die Fragen der Zukunft sind: „Wie können IT-Abteilungen in Krankenhäusern die Herausforderung meistern, die sich aus der aktuellen Gesetzeslage ergeben?“ als auch „Wie können Hersteller und Betreiber darauf hinwirken, dass die Auslegung z.B. hinsichtlich der Klassifizierung der Software-Medizinprodukte in einem technisch und formal umsetzbaren Rahmen bleibt?“.

Für die IT-Abteilungen wird die Einführung eines Änderungsmanagements, dem die als Medizinprodukt betriebenen Systeme zu unterwerfen sind, unvermeidlich. Die Schulung der Anwender und Betreiber muss dokumentiert durchgeführt werden (vgl. [MPBetreibV]). Die Beschaffungs- und Integrationsprozesse müssen um die IEC 80001-1 herum organisiert werden und es muss in jedem Fall ein Medizinproduktebuch geführt werden.

Hierbei ist es unverzichtbar, dass die Nachvollziehbarkeit einer Konfiguration der Medizinprodukte zu einem bestimmten Zeitpunkt gewährleistet ist, um im Falle eines Patientenschadens die Klärung der Ursachen durchführen zu können, die zu dieser Gefährdung führten. (Nachvollziehbarkeit, technisch „Traceability“ genannt, ist ein wichtiges Kriterium von Medizinprodukten. Ein Fehlverhalten muss nachvollziehbar sein.) Es müssen also für alle betroffenen Softwaremedizinprodukte Mechanismen gefunden und implementiert werden, die eine derartige Nachvollziehbarkeit ermöglichen. Dies wird nicht ohne zusätzliches Personal und Kompetenzen geschehen können.

Besonders die kleineren Krankenhäuser der Versorgungstufen 2 und 3 und Arztpraxen werden von der letztgenannten Problematik hart getroffen und es fragt sich, wie sie einen Betrieb solcher Funktionen meistern sollen.


Begrenzter Nutzen von Zertifizierungen

Schützen Zertifizierungen von Krankenhäusern gegen die systematische Fehlnutzung von Medizinsoftware? Die im Juli 2010 durch Hygieneprobleme aufgefallene Krankenhäuser des Klinikums München [17] waren erst kurz zuvor nach KTQ zertifiziert [18], [19] worden, dabei waren selbst diese eklatanten und von medizinischen Auditoren fachlich leicht hinterfragbaren Mängel offenbar nicht aufgefallen. Bei technischen Produkten ist die Hinterfragbarkeit durch medizinische Spezialisten noch weit weniger gegeben, sind doch schon technische Spezialisten überfordert. Die eingangs genannte CT-Software, die zur Verstrahlung von Patienten führte, wurde von einem MP-zertifizierten Hersteller geliefert. Es bleibt also kritisch zu hinterfragen, was sich konkret mit einer Änderung in der MDD durch die Einführung der Bedeutung „Software als eigenständiges Medizinprodukt“ und damit einer Überführung vieler EDV Komponenten in den regulatorischen Bereich der Medizinprodukte ändern wird.


Entwicklung darf nicht abwandern

Es muss ein Weg geschaffen werden, wie wir es ermöglichen, dass auch in Zukunft noch anspruchsvolle Medizin-Software in Europa entwickelt und betrieben werden kann, die auch weiterhin von Krankenhäusern bei Bedarf auf die dortige Situation angepasst werden kann. Der gesamte Wertschöpfungsprozess des Herstellens, der Konfiguration/Parametrierung und des Einsatzes medizinischer Software muss in allen Facetten weiterhin möglich sein und darf nicht vor übertriebener Bürokratie, die aus Haftungsgründen hohe Anforderungen stellt, zurückweichen. Dies gilt umso mehr, als das „Haftungsszenario“ im Schadensfall trotz aller administrativer Bemühungen auch nach der jetzt erfolgten Novelle kaum klarer wurde. Es wurden viele neue Ansatzpunkte für Klagen gegen Softwarehersteller und -betreiber geschaffen, der klinische Mehrwert für die Sicherheit der Patienten gegenüber den vorbestehenden Regelungen ist bisher aber nicht erkennbar.

Die aktuellen Regelungen fördern leider eine Grundeinstellung, dass selbst jegliche Stand-Alone Software die mit medizinischer Zweckbestimmung eingesetzt wird, grundsätzlich gefährlich ist. Dies lässt sich bereits jetzt bei der Genehmigung von Forschungsvorhaben in diesem Bereich feststellen, wo mittlerweile Ethikkommissionen von den Forschern eine sofortige Stellungnahme zur MPG-Einordung der geplanten Arbeiten fordern und die Arbeiten bis dahin – juristisch gesehen korrekt, aber aus dem Blickwinkel der Forschung betrachtet fatal – blockieren. Wir appellieren an dieser Stelle an eine maßvolle Ausgestaltung. Meist ist davon auszugehen, dass Ärzte und Experten aus der medizinischen Informatik oder aus dem Bereich der medizinischen Versorgung bereits heute durch ihre Kenntnisse des medizinischen Betriebs und der ärztlichen Kunst die Sicherheit und Effektivität einer medizinischen Behandlung in den Vordergrund stellen. Schon alleine deshalb werden sie Software nie als Entscheidungsersatz, wohl aber als facettenreiche Unterstützung in einem Strauß von Argumenten nutzen und weiter nutzen wollen. Ein Aspekt, den der Gesetzgeber in Brüssel offenbar so nicht verstanden hat, als er die neuen Regelungen beschloss.


Anmerkung

Interessenkonflikte

Die Autoren erklären, dass sie keine Interessenkonflikte in Zusammenhang mit diesem Artikel haben.


Literatur

1.
Luzi D, Pecorao F. Medical Device Software: A New Challenge. In: Quality of Life through Quality of Information. Proceedings of MIE 2012; August 2012; Pisa, Italy.
2.
Verordnung über das Errichten, Betreiben und Anwenden von Medizinprodukten (MPBetreibV). §2, 1. Absatz. Available from: http://www.gesetze-im-internet.de/bundesrecht/mpbetreibv/gesamt.pdf Externer Link
3.
Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG). §3, 10. Absatz. Available from: http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf Externer Link
4.
Richtlinie 2007/47/eg des Europäischen Parlaments und des Rates vom 5. September 2007 zur Änderung der Richtlinien 90/385/EWG des Rates zur Angleichung der Rechtsvorschriften der Mitgliedstaaten über aktive implantierbare medizinische Geräte und 93/42/EWG des Rates über Medizinprodukte sowie der Richtlinie 98/8/EG über das Inverkehrbringen von Biozid-Produkten. Amtsblatt der Europäischen Union. 2007:L 247/21.
5.
Bogdanich W. The Radiation Boom. After Stroke Scans, Patients Face Serious Health Risks. The New York Times. July 31, 2010. Available from: http://www.nytimes.com/2010/08/01/health/01radiation.html?pagewanted=all Externer Link
6.
European Commission. Guidelines on the Qualification and Classification of Stand alone Software used in Healthcare within the Regulatory Framework of Medical Devices. MEDDEV 2.1/6. January 2012. Available from: http://ec.europa.eu/health/medical-devices/files/meddev/2_1_6_ol_en.pdf Externer Link
7.
Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG). §3, 1. Absatz, Abschnitt a). Bundesministerium der Justiz; 2012. Available from: http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf Externer Link
8.
Europäische Union. Richtlinie 93/42/EWG des Rates vom 14. Juni 1993 über Medizinprodukte in der Fassung vom 11.10.2007. S.56ff. Available from: http://eur-lex.europa.eu/LexUriServ/site/de/consleg/1993/L/01993L0042-20071011-de.pdf Externer Link
9.
European Committee for Electrotechnical Standardization. EN 62304:2006 “Medical device software - Software life-cycle processes”. Brussels; 2006.
10.
Verordnung über das Errichten, Betreiben und Anwenden von Medizinprodukten (Medizinprodukte-Betreiberverordnung - MPBetreibV). Bundesministerium der Justiz; 2009. Available from: http://www.gesetze-im-internet.de/bundesrecht/mpbetreibv/gesamt.pdf Externer Link
11.
Europäische Union. Richtlinie 93/42/EWG des Rates vom 14. Juni 1993 über Medizinprodukte. Available from: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1993L0042:20071011:de:PDF Externer Link
12.
Manual on Borderline and Classification in the Community. Regulatory framework for medical devices. Available from: http://ec.europa.eu/health/medical-devices/files/wg_minutes_member_lists/borderline_manual_ol_en.pdf Externer Link
13.
Verordnung über Medizinprodukte (Medizinprodukte-Verordnung - MPV). Available from: http://www.gesetze-im-internet.de/bundesrecht/mpv_2002/gesamt.pdf Externer Link
14.
Reggia J, Thurim S, eds. Computer-assisted Medical Decision Making. Vol. 1. New York, Berlin, Heidelberg, Tokio: Springer Verlag; 1985. p. 3-45.
15.
Grätzel von Grätz P. Abwarten und Tee trinken. eHealth. Jan 2010:28-29.
16.
Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG). §2, 2. Absatz. Available from: http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf Externer Link
17.
Hygieneskandal an Kliniken. Verschmutzungen mit bloßem Auge zu sehen. Süddeutsche Zeitung vom 8. Juli 2010. Available from: http://www.sueddeutsche.de/muenchen/hygiene-skandal-verschmutzungen-mit-blossem-auge-zu-sehen-1.972200 Externer Link
18.
Institut KTQ (Kooperation für Qualitäts und Transparenz im Gesundheitswesen). Qualitätsbericht Städtisches Klinikum München GmbH - Klinikum Bogenhausen. 21. August 2009. Available from: http://www.klinikum-muenchen.de/fileadmin/01-Unternehmen/03-Qualitaet/Qualitaetsbericht/KTQ_QB_KB_2010.pdf Externer Link
19.
Institut KTQ (Kooperation für Qualitäts und Transparenz im Gesundheitswesen). Qualitätsbericht Städtisches Klinikum Neuperlach, München. 2009. Available from: http://www.klinikum-muenchen.de/fileadmin/01-Unternehmen/03-Qualitaet/Qualitaetsbericht/KTQ_2009_KN.pdf Externer Link