gms | German Medical Science

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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