mibe000127
10.3205/mibe000127
urn:nbn:de:0183-mibe0001273
Übersichtsarbeit
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
Kaiser
Kaiser
J.
J
Universitätsklinikum Erlangen, ÄD, Östliche Stadtmauerstraße 30a, 91054 Erlangen, Deutschland, Tel.: 09131/85-36205Universitätsklinikum Erlangen, Deutschland
Jochen.Kaiser@uk-erlangen.de
author
Gassner
Gassner
U.M.
UM
Universität Augsburg, Forschungsstelle für Medizinprodukterecht, Augsburg, Deutschland
Ulrich.Gassner@jura.uni-augsburg.de
author
Reng
Reng
M.
M
MedicDat GmbH & Med. Fakultät der Univ. Regensburg, Deutschland
Michael.Reng@medicdat.de
author
Prokosch
Prokosch
H.U.
HU
Universität Erlangen-Nürnberg, Lehrstuhl für medizinische Informatik, Erlangen, Deutschland
Ulli.Prokosch@imi.med.uni-erlangen.de
author
Bürkle
Bürkle
T.
T
Universität Erlangen-Nürnberg, Lehrstuhl für medizinische Informatik, Erlangen, Deutschland
Thomas.Buerkle@imi.med.uni-erlangen.de
author
German Medical Science GMS Publishing House
Düsseldorf
610
20121212
germ
1860-9171
8
1
GMS Medizinische Informatik, Biometrie und Epidemiologie
GMS Med Inform Biom Epidemiol
03
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.
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.
EinleitungNoch 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 RahmenDie 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 ) 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 , 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 . 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-Softw<![CDATA[are</PlainText></TextGroup>“ 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 <TextLink reference="4"></TextLink>, 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.</Pgraph></TextBlock>
<TextBlock linked="yes" name="Patientengefährdung">
<MainHeadline>Patientengefährdung</MainHeadline><Pgraph>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 <TextLink reference="5"></TextLink>. 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.</Pgraph><Pgraph>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.</Pgraph><Pgraph>Durch die Meddev 2.1/6 <TextLink reference="6"></TextLink> 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.</Pgraph><Pgraph>Ob der Einsatz einer Software dem Zweck der Diagnostik oder Therapie dient und damit der Medizinprodukteregelung unterliegt <TextLink reference="7"></TextLink>, 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. </Pgraph></TextBlock>
<TextBlock linked="yes" name="Neuerungen 2010 und 2011 fordern Hersteller und Kliniken">
<MainHeadline>Neuerungen 2010 und 2011 fordern Hersteller und Kliniken</MainHeadline><Pgraph>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.</Pgraph><Pgraph>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 <TextLink reference="8"></TextLink>. Die „Klarstellung“ der EU hat zudem erschwerend die EN 62304 <TextLink reference="9"></TextLink> im Schlepptau, die das Software-Lebenszyklusmodell für Medizinproduktsoftware und damit auch für alle eigenständigen Softwaremedizinprodukte verbindlich macht.</Pgraph><Pgraph>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. </Pgraph><Pgraph>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? </Pgraph><Pgraph>Durch die Einordnung der IT-Systeme als Medizinprodukt ist die bisherige flexible Handhabung jeglicher Parametrierung gefährdet, die Medizinproduktebetreiberverordnung <TextLink reference="10"></TextLink> sieht hierfür keine verbindliche Regelung vor.</Pgraph><SubHeadline3>Beispiel</SubHeadline3><Pgraph><Mark2>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. </Mark2><LineBreak></LineBreak><LineBreak></LineBreak>Auch wenn es sich bei der Novelle der Richtlinie 93/42/EWG <TextLink reference="11"></TextLink> 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. </Pgraph><Pgraph>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 <TextLink reference="12"></TextLink> 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.</Pgraph><Pgraph>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. </Pgraph></TextBlock>
<TextBlock linked="yes" name="Klassifizierung als Innovationshindernis">
<MainHeadline>Klassifizierung als Innovationshindernis</MainHeadline><Pgraph>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.</Pgraph><Pgraph><Mark1>Risikoklassifizierung</Mark1> entsprechend Anhang IX der Richtlinie 93/42/EWG</Pgraph><Pgraph><UnorderedList><ListItem level="1"><Mark1>Klasse I</Mark1> – Keine methodische Risiken, geringer Invasivitätsgrad</ListItem><ListItem level="1"><Mark1>Klasse IIa</Mark1> – Anwendungsrisiko, mäßiger Invasivitätsgrad</ListItem><ListItem level="1"><Mark1>Klasse IIb</Mark1> – Erhöhtes methodisches Risiko, systemische Wirkungen, Langzeitanwendungen </ListItem><ListItem level="1"><Mark1>Klasse III</Mark1> – hohes Gefahrenpotential</ListItem></UnorderedList></Pgraph><Pgraph>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 Standa<TextGroup><PlainText>lon</PlainText></TextGroup>e-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. </Pgraph><Pgraph>Die Einstufung einer Software als Medizinprodukt kann für Hersteller und Betreiber erhebliche Auswirkungen haben. Zunächst sind das Aufwand und Kosten. Die MPV <TextLink reference="13"></TextLink> 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 <TextGroup><PlainText>Schnit</PlainText></TextGroup>tstellen 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.</Pgraph><Pgraph>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. </Pgraph><Pgraph>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. </Pgraph><Pgraph>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.</Pgraph><Pgraph>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.</Pgraph><Pgraph>Führende Medizininformatiker und Ärzte betonen seit Jahrzehnten: „medical decision support functions support the physician and never replace him or his final intellectual decision <TextLink reference="14"></TextLink>“. Diese Überlegungen werden in der Meddev 2.1/6 nicht gewürdigt.</Pgraph></TextBlock>
<TextBlock linked="yes" name="Die Herstellerklassifikation löst das Problem aktuell noch nicht vollständig">
<MainHeadline>Die Herstellerklassifikation löst das Problem aktuell noch nicht vollständig</MainHeadline><Pgraph>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.</Pgraph><SubHeadline3>Beispiel: Befundung mit nicht befundungsfähigen Monitoren</SubHeadline3><Pgraph><Mark2>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. </Mark2></Pgraph><Pgraph><Mark2>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.</Mark2></Pgraph><Pgraph><Mark2>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 Softw</Mark2><TextGroup><Mark2>are</Mark2></TextGroup><Mark2> 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. </Mark2><LineBreak></LineBreak><LineBreak></LineBreak>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 <TextLink reference="15"></TextLink>. 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<Superscript>®</Superscript> 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.</Pgraph></TextBlock>
<TextBlock linked="yes" name="Verantwortung des Betreibers auch bei Fehlklassifizierung">
<MainHeadline>Verantwortung des Betreibers auch bei Fehlklassifizierung</MainHeadline><Pgraph>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“).</Pgraph><Pgraph><Mark1>Bei anderweitiger oder erweiterter Verwendung eines Medizinprodukts am bestimmungsgemäßen Gebrauch vorbei, obliegt dem Betreiber im Schadensfall die Verantwortung.</Mark1></Pgraph><Pgraph>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 <TextLink reference="16"></TextLink>.</Pgraph><Pgraph>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. <Mark2>(Die Vigilanz im Rahmen von Medizinprodukten wird in Deutschland durch die „Verordnung über die Erfassung, Bewertung und Abwehr von Risiken bei Medizinprodukten“ (MPSV) geregelt.)</Mark2></Pgraph></TextBlock>
<TextBlock linked="yes" name="IT-Abteilung wird zum Medizinproduktbetreiber">
<MainHeadline>IT-Abteilung wird zum Medizinproduktbetreiber</MainHeadline><Pgraph>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?“.</Pgraph><Pgraph>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. </Pgraph><Pgraph>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. <Mark2>(Nachvollziehbarkeit, technisch „Traceability“ genannt, ist ein wichtiges Kriterium von Medizinprodukten. Ein Fehlverhalten muss nachvollziehbar sein.)</Mark2> 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.</Pgraph><Pgraph>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. </Pgraph></TextBlock>
<TextBlock linked="yes" name="Begrenzter Nutzen von Zertifizierungen">
<MainHeadline>Begrenzter Nutzen von Zertifizierungen</MainHeadline><Pgraph>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 <TextLink reference="17"></TextLink> waren erst kurz zuvor nach KTQ zertifiziert <TextLink reference="18"></TextLink>, <TextLink reference="19"></TextLink> 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. </Pgraph></TextBlock>
<TextBlock linked="yes" name="Entwicklung darf nicht abwandern">
<MainHeadline>Entwicklung darf nicht abwandern</MainHeadline><Pgraph>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.</Pgraph><Pgraph>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.</Pgraph></TextBlock>
<TextBlock linked="yes" name="Anmerkung">
<MainHeadline>Anmerkung</MainHeadline><SubHeadline>Interessenkonflikte</SubHeadline><Pgraph>Die Autoren erklären, dass sie keine Interessenkonflikte in Zusammenhang mit diesem Artikel haben.</Pgraph></TextBlock>
<References linked="yes">
<Reference refNo="1">
<RefAuthor>Luzi D</RefAuthor>
<RefAuthor>Pecorao F</RefAuthor>
<RefTitle>Medical Device Software: A New Challenge</RefTitle>
<RefYear></RefYear>
<RefBookTitle>Quality of Life through Quality of Information.</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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.</RefTotal>
</Reference>
<Reference refNo="2">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>§2, 1. Absatz</RefTitle>
<RefYear></RefYear>
<RefBookTitle>Verordnung über das Errichten, Betreiben und Anwenden von Medizinprodukten (MPBetreibV)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://www.gesetze-im-internet.de/bundesrecht/mpbetreibv/gesamt.pdf</RefLink>
</Reference>
<Reference refNo="3">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>§3, 10. Absatz</RefTitle>
<RefYear></RefYear>
<RefBookTitle>Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG). §3, 10. Absatz. Available from: http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf</RefTotal>
<RefLink>http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf</RefLink>
</Reference>
<Reference refNo="4">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>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</RefTitle>
<RefYear>2007</RefYear>
<RefJournal>Amtsblatt der Europäischen Union</RefJournal>
<RefPage>L 247/21</RefPage>
<RefTotal>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.</RefTotal>
</Reference>
<Reference refNo="5">
<RefAuthor>Bogdanich W</RefAuthor>
<RefTitle>The Radiation Boom. After Stroke Scans, Patients Face Serious Health Risks</RefTitle>
<RefYear>2010</RefYear>
<RefJournal>The New York Times</RefJournal>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://www.nytimes.com/2010/08/01/health/01radiation.html?pagewanted=all</RefLink>
</Reference>
<Reference refNo="6">
<RefAuthor>European Commission</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2012</RefYear>
<RefBookTitle>Guidelines on the Qualification and Classification of Stand alone Software used in Healthcare within the Regulatory Framework of Medical Devices. MEDDEV 2.1/6</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://ec.europa.eu/health/medical-devices/files/meddev/2_1_6_ol_en.pdf</RefLink>
</Reference>
<Reference refNo="7">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>§3, 1. Absatz, Abschnitt a)</RefTitle>
<RefYear>h2012</RefYear>
<RefBookTitle>Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf</RefLink>
</Reference>
<Reference refNo="8">
<RefAuthor>Europäische Union</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2007</RefYear>
<RefBookTitle>Richtlinie 93/42/EWG des Rates vom 14. Juni 1993 über Medizinprodukte in der Fassung vom 11.10.2007</RefBookTitle>
<RefPage>56ff</RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://eur-lex.europa.eu/LexUriServ/site/de/consleg/1993/L/01993L0042-20071011-de.pdf</RefLink>
</Reference>
<Reference refNo="9">
<RefAuthor>European Committee for Electrotechnical Standardization</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2006</RefYear>
<RefBookTitle>EN 62304:2006 “Medical device software - Software life-cycle processes”</RefBookTitle>
<RefPage></RefPage>
<RefTotal>European Committee for Electrotechnical Standardization. EN 62304:2006 “Medical device software - Software life-cycle processes”. Brussels; 2006.</RefTotal>
</Reference>
<Reference refNo="10">
<RefAuthor>Anonym</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2009</RefYear>
<RefBookTitle>Verordnung über das Errichten, Betreiben und Anwenden von Medizinprodukten (Medizinprodukte-Betreiberverordnung - MPBetreibV)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://www.gesetze-im-internet.de/bundesrecht/mpbetreibv/gesamt.pdf</RefLink>
</Reference>
<Reference refNo="11">
<RefAuthor>Europäische Union</RefAuthor>
<RefTitle></RefTitle>
<RefYear></RefYear>
<RefBookTitle>Europäische Union. Richtlinie 93/42/EWG des Rates vom 14. Juni 1993 über Medizinprodukte</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1993L0042:20071011:de:PDF</RefLink>
</Reference>
<Reference refNo="13">
<RefAuthor>Anonym</RefAuthor>
<RefTitle></RefTitle>
<RefYear></RefYear>
<RefBookTitle>Verordnung über Medizinprodukte (Medizinprodukte-Verordnung - MPV)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Verordnung über Medizinprodukte (Medizinprodukte-Verordnung - MPV). Available from: http://www.gesetze-im-internet.de/bundesrecht/mpv_2002/gesamt.pdf</RefTotal>
<RefLink>http://www.gesetze-im-internet.de/bundesrecht/mpv_2002/gesamt.pdf</RefLink>
</Reference>
<Reference refNo="14">
<RefAuthor>Reggia J</RefAuthor>
<RefAuthor>Thurim S</RefAuthor>
<RefTitle></RefTitle>
<RefYear>1985</RefYear>
<RefBookTitle>Computer-assisted Medical Decision Making</RefBookTitle>
<RefPage>3-45</RefPage>
<RefTotal>Reggia J, Thurim S, eds. Computer-assisted Medical Decision Making. Vol. 1. New York, Berlin, Heidelberg, Tokio: Springer Verlag; 1985. p. 3-45.</RefTotal>
</Reference>
<Reference refNo="15">
<RefAuthor>Grätzel von Grätz P</RefAuthor>
<RefTitle>Abwarten und Tee trinken</RefTitle>
<RefYear>Jan</RefYear>
<RefJournal>eHealth</RefJournal>
<RefPage>28-29</RefPage>
<RefTotal>Grätzel von Grätz P. Abwarten und Tee trinken. eHealth. Jan 2010:28-29.</RefTotal>
</Reference>
<Reference refNo="16">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>§2, 2. Absatz</RefTitle>
<RefYear></RefYear>
<RefBookTitle>Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Gesetz über Medizinprodukte (Medizinproduktegesetz - MPG). §2, 2. Absatz. Available from: http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf</RefTotal>
<RefLink>http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf</RefLink>
</Reference>
<Reference refNo="17">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>Hygieneskandal an Kliniken. Verschmutzungen mit bloßem Auge zu sehen</RefTitle>
<RefYear>2010</RefYear>
<RefJournal>Süddeutsche Zeitung</RefJournal>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://www.sueddeutsche.de/muenchen/hygiene-skandal-verschmutzungen-mit-blossem-auge-zu-sehen-1.972200</RefLink>
</Reference>
<Reference refNo="18">
<RefAuthor>Institut KTQ (Kooperation für Qualitäts und Transparenz im Gesundheitswesen)</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2009</RefYear>
<RefBookTitle>Qualitätsbericht Städtisches Klinikum München GmbH - Klinikum Bogenhausen</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://www.klinikum-muenchen.de/fileadmin/01-Unternehmen/03-Qualitaet/Qualitaetsbericht/KTQ_QB_KB_2010.pdf</RefLink>
</Reference>
<Reference refNo="19">
<RefAuthor>Institut KTQ (Kooperation für Qualitäts und Transparenz im Gesundheitswesen)</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2009</RefYear>
<RefBookTitle>Qualitätsbericht Städtisches Klinikum Neuperlach, München</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://www.klinikum-muenchen.de/fileadmin/01-Unternehmen/03-Qualitaet/Qualitaetsbericht/KTQ_2009_KN.pdf</RefLink>
</Reference>
<Reference refNo="12">
<RefAuthor>Anonym</RefAuthor>
<RefTitle></RefTitle>
<RefYear></RefYear>
<RefBookTitle>Manual on Borderline and Classification in the Community. Regulatory framework for medical devices</RefBookTitle>
<RefPage></RefPage>
<RefTotal>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</RefTotal>
<RefLink>http://ec.europa.eu/health/medical-devices/files/wg_minutes_member_lists/borderline_manual_ol_en.pdf</RefLink>
</Reference>
</References>
<Media>
<Tables>
<NoOfTables>0</NoOfTables>
</Tables>
<Figures>
<NoOfPictures>0</NoOfPictures>
</Figures>
<InlineFigures>
<NoOfPictures>0</NoOfPictures>
</InlineFigures>
<Attachments>
<NoOfAttachments>0</NoOfAttachments>
</Attachments>
</Media>
</OrigData>
</GmsArticle>]]></plaintext></textgroup></pgraph></textblock></origdata></gmsarticle>