Jusletter IT

Eine allgemein anerkannte und umfassende Definition für«Cloud Computing» existiert bis zum aktuellen Zeitpunkt noch nicht, jedoch wird darunter weitgehend die Bereitstellung bzw. Inanspruchnahme von IT-Ressourcen in unterschiedlicher Ausformung über das Internet verstanden. Meistens kommen beim Serviceprovider zur effizienteren Ressourcennutzung und Skalierbarkeit der zu erbringenden Rechenleistung auch Virtualisierungstechniken zum Einsatz, jedoch ist dies aber nicht notwendige Voraussetzung. Im Zuge der Nutzung vonInfrastructure as a Service (IaaS) stellt der Serviceprovider dem Nutzer bestimmte Infrastrukturkomponenten wie beispielsweise Speicherplatz oder eine entsprechende Umgebung zur Verwaltung und zum Betrieb von Virtuellen Instanzen zur Verfügung. Für deren Erzeugung und Konfiguration ist der Nutzer jedoch selbst verantwortlich. Eine weitere Variante des Cloud Computings bildetPlatform as a Service (PaaS). Dabei wird den Nutzern neben der technischen Infrastruktur auch eine zentrale Plattform zur Entwicklung von Software zur Verfügung gestellt. Die letzte und für den Bereich der medizinischen Informatik wohl interessanteste Variante bildetSoftware as a Service (SaaS). Bei dieser Variante werden den Cloud-Nutzern gesamte Applikationen über das Internet zur Verfügung gestellt, die unter Implementierung eines entsprechenden Berechtigungssystems auch von mehreren Gesundheits-diensteanbietern (GDA) genutzt werden können. Der Zugriff auf diese Applikationen kann direkt durch den Benutzer unter Verwendung seines Browsers oder programmgesteuert über bestimmte definierte Schnittstellen erfolgen. Sicherer Betrieb, Wartung und Aktualisierung der Software sowie die Datensicherung werden vom Service-Provider übernommen.¹

Auf Grund der Sensibilität medizinischer Daten kann ein SaaS-Serviceprovider im medizinischen Bereich wohl nur als Dienstleister gem. § 4 Z. 5 DSG zum Einsatz kommen, da bei diesem die Verarbeitung der Daten nicht zu eigenen Zwecken und nicht «im eigenen Interesse» erfolgt, sondern lediglich auf Weisung und somit als «verlängerter Arm» der Auftraggeber. Datenschutzrechtliche Auftraggeber bleiben die einzelnen Gesundheitsdiensteanbieter (GDA), welche die Dienste der Provider in Anspruch nehmen, und sind daher auch weiterhin für die Gewährleistung der rechtlichen Zulässigkeit und technischen Sicherheit der Datenverarbeitung verantwortlich. Jedoch auch die Zulässigkeit einer Datenüberlassung ist an gewisse Voraussetzungen gebunden: So sind einerseits die Allgemeinen Grundsätze der Verwendung von Daten gem. § 6 DSG einzuhalten, andererseits müssen aber auch die Zulässigkeitsvoraussetzungen der § 7 Abs. 1 und 3 DSG beim Auftraggeber erfüllt sein, da eine Datenüberlassung nur dann zulässig ist, wenn die Daten davor auch zulässiger Weise beim Auftraggeber verarbeitet wurden.

Dass die Verarbeitung von Patientendaten bei einem GDA dessen gesetzlicher Zuständigkeit bzw. rechtlichen Befugnis entspricht (§ 7 Abs. 1 DSG), davon wird man zweifellos ausgehen dürfen. Auch schutzwürdige Geheimhaltungsinteressen der Patienten werden bei der Verarbeitung von Gesundheitsdaten nicht verletzt, da dies auf Grund einer gesetzlichen Grundlage geschieht² .

Dabei ist jedoch zu beachten, dass Patientendaten nur für den Zweck der Dokumentation von Diagnose, Beratung und Behandlung sowie der Führung von Krankengeschichten erhoben und gespeichert werden dürfen («Zweckbindungsgrundssatz» gem. § 6 Abs. 1 Z. 2 DSG) und nicht mehr Daten erhoben werden dürfen, als für die Erreichung dieses Zwecks notwendig sind («Wesentlichkeitsgrundsatz» gem. § 6 Abs. 1 Z. 3 DSG). In § 7 Abs. 3 DSG werden für eine zulässige Datenverwendung das Erfordernis der Wahrung des Verhältnismäßigkeitsgrundsatzes, sowie die Einhaltung der Grundsätze einer ordnungsgemäßen Datenverwendung gem. § 6 DSG festgeschrieben. Ein Eingriff in das Grundrecht auf Datenschutz darf somit nur im erforderlichen Ausmaß erfolgen und muss das gelindeste zur Verfügung stehende Mittel darstellen.

Dass Patientendaten im Zuge der Erfüllung eines Behandlungsvertrages von einem GDA zulässiger Weise verarbeitet werden dürfen bzw. sogar müssen, daran ist – wie im vorhergehenden Kapitel dargelegt – nicht zu zweifeln.

«Sind diese Kriterien erfüllt, kann der Auftraggeber die Daten ohne weitere Prüfung dem Dienstleister überlassen, soweit dieser die Kriterien der §§ 10 und 11 DSG 2000 erfüllt; […] Eine weitere Prüfung, ob die Daten überlassen werden dürfen, wie dies bei Übermittlungen an andere Auftraggeber nach § 7 Abs. 2 DSG 2000 notwendig ist, muss nicht erfolgen.[…]»³ Die Regelungen des § 7 DSG sind somit bei einer Datenüberlassung nicht anwendbar.⁴

Für die Gewähr einer rechtmäßigen und sicheren Datenanwendung finden sich in der Literatur unterschiedliche Erfordernisse an eine solche Prüfpflicht:Dohr/Pollirer/Weiss⁵ erachten es als ausreichend, wenn die gewerberechtliche Befugnis gem. § 153 GewO zur Ausübung des Gewerbes «Dienstleistungen in der automationsunterstützten Datenverarbeitung und Informationstechnik» vorliegt,Drobesch/Grosinger⁶ knüpfen daran das Erfordernis der Vorlage und Prüfung eines Sicherheitskonzepts bereits vor Aufnahme der Tätigkeit durch den Dienstleister.

Zu beachten ist in diesem Zusammenhang jedoch, dass neben einer Datenübermittlung auch eine Datenüberlassung an Dienstleister außerhalb des EWR nur unter den Voraussetzungen des § 12 DSG genehmigungsfrei zulässig ist. Anderenfalls ist die Genehmigung der Datenschutzkommission einzuholen. Somit ist bei der Auswahl des Dienstleisters bzw. in der vertraglichen Vereinbarung mit diesem darauf zu achten, in welchen Staaten konkret die Verarbeitung der überlassenen Daten erfolgt bzw. erfolgen darf, um das Erfordernis einer Genehmigung zu vermeiden.

Mit dem Gesundheitsreformgesetz 2005 wurde auch das Gesundheitstelematikgesetz (GTelG)⁷ erlassen, durch welches ergänzende datenschutzrechtliche Bestimmungen im Bereich des Gesundheitswesens und somit im Bezug auf die Verwendung von Gesundheitsdaten erlassen wurden.⁸ Zur Konkretisierung dieses Gesetzes wurde auf dessen Grundlage die Gesundheitstelematikverordnung (GTelV)⁹ erlassen, welche konkrete technische Anforderungen an elektronische Gesundheitssysteme und den elektronischen Gesundheitsdatenaustausch festlegt.

Unter «Gesundheitsdiensteanbietern» versteht das GTelG Auftraggeberund Dienstleister iSd DSG 2000, deren regelmäßige Verwendung von Gesundheitsdaten Bestandteil ihrer Erwerbstätigkeit, ihres Betriebszwecks oder ihres Dienstleistungsangebotes ist (§ 2 Z. 2 GTelG). Die Legaldefinition von «Gesundheitsdaten» findet sich in § 2 Z. 1 GTelG und umfasst grob umschrieben alle direkt personenbezogenen Daten iSd. 4 Z. 1 DSG 2000, welche direkt oder indirekt Rückschlüsse auf den Gesundheitszustand einer Person liefern.

Aus Datensicherheitsgründen schreibt das Gesundheitstelematikgesetz vor, dass bei jeder Weitergabe von Gesundheitsdaten an einen anderen GDAs oder bei der Einräumung einer Zugriffsmöglichkeit auf solche Daten die Identität und die Rolle des Gesundheitsdatenempfängers nachgewiesen¹⁰ sowie die Vertraulichkeit¹¹ und die Integrität¹² der Daten bei ihrer Übertragung gesichert sein muss. Da auch ein Dienstleister als GDA zu qualifizieren ist, sind diese Erfordernisse auch bei einer Datenüberlassung iSd. § 4 Z. 11 DSG zu erfüllen.

Abhängig von der technischen Umsetzung können Integrität, Vertraulichkeit und Nachweis der Rolle auf unterschiedliche Art und Weise sichergestellt werden. Im Bereich von SaaS wird in den meisten Fällen die Bereitstellung einer für den Benutzer zugänglichen Webapplikation, eines Webservices oder einer anderen definierten Schnittstelle in Frage kommen. In der ersten Variante wird dem Benutzer die Software von einem Webserver über das Internet zur Verfügung gestellt, welche z.B. durch Eingabe der entsprechenden URL aufgerufen werden kann. In diesem Fall spricht das GTelG etwas sperrig von «Bedienung einer Datenanwendung aus der Ferne». Die zweite Variante bezeichnet das Gesetz als «ausschließlich programmgesteuerte Abwicklung» des Gesundheitsdatenaustausches. Für beide Varianten sehen die §§ 4-7 GTelG jedoch bestimme Erleichterungen zu den sonst strengeren Anforderungen an die Datensicherheit beim Gesundheitsdatenaustausch über das Internet (z.B. per E-Mail) vor, sofern deren Umsetzungim Einzelfall aus technischen oder wirtschaftlichen Gründen unzweckmäßig erscheint.¹³

Eine solche Unzweckmäßigkeit kann u.E. in der Regel hinsichtlich der Identität und Rolle dann angenommen werden, wenn die beiden Kommunikationspartner einander kennen und so die Identität und Rolle des jeweils anderen Kommunikationspartners ohnedies nachweislich bekannt ist. Als verstärkendes Element kommt in der Beziehung zwischen Cloud-Provider und Cloud-Nutzer hinzu, dass zwischen diesen ein Vertragsverhältnis bestehen muss (vgl. § 10 DSG). Eine Identifizierung des Benutzers durch Benutzername und Passwort wird in solchen Fällen daher als ausreichend angesehen werden können, insbesondere dann, wenn die einzelnen Benutzer in ihrem alltäglichen Arbeitsablauf unterschiedliche PCs verwenden müssen. Die Notwendigkeit der Verwendung einer Smartcard zur Identifizierung erweist sich vor allem in Krankenanstalten oftmals dann als unpraktikabel, wenn die betroffenen Personen auch häufig ihre Bekleidung wechseln müssen, da Smartcards in der Regel in dieser aufbewahrt werden und so das Risiko des Vergessens darin besteht.

Für die Sicherstellung der Vertraulichkeit sind gem. § 6 GTelG kryptographische Verfahren einzusetzen, die nach dem jeweiligen Stand der Technik mit wirtschaftlich vertretbarem Aufwand nicht kompromittiert werden können¹⁴ , sofern die Daten über ein Medium transportiert werden, das nicht ihrem ausschließlichen Zugriff unterliegt (z.B. Internet, WANs oder WLANs¹⁵ ). Weiters müssen die Daten in der Form einer Ende-zu-Ende-Verschlüsselung an den Dienstleister als Empfänger übermittelt werden. Gemäß § 3 Abs. 1 Z. 2 GTelV ist die Vertraulichkeit der übertragenen Daten dann hinreichend sichergestellt, wenn diese vollständig verschlüsselt werden und dabei einer der in Anhang 2 der Verordnung genannten Algorithmen zum Einsatz kommt.¹⁶ Die Integrität der übermittelten Daten ist gem. § 7 GTelG in der Regel durch elektronische Signaturen sicherzustellen, jedoch können bei der Bedienung aus der Ferne bzw. beim ausschließlich automationsunterstützten Datenaustausch auch andere Maßnahmen oder Verfahren zum Einsatz kommen, sofern sie ein vergleichbares Datensicherheitsniveau gewährleisten.

Beide Erfordernisse können dadurch erfüllt werden, dass Webapplikationen oder entsprechende Schnittstellen als SaaS-Services nur über SSL (TLS)¹⁷ verwendet oder angesprochen werden können. Sobald ein Benutzer eine Verbindung zu einem solchen Service initialisiert, erfolgt der Verbindungsaufbau unter Verwendung von TLS. Erst danach wird dem Benutzer der Dialog zur Eingabe seiner Benutzerdaten angezeigt, wodurch diese in jedem Fall verschlüsselt übermittelt werden.¹⁸ TLS stellt auch die Prüfung der Integrität der übertragenen Daten sicher. Zum Nachweis der Identität des Betreibers des Servers muss die TLS-Verbindung serverseitig durch ein vertrauenswürdiges Zertifikat gesichert sein, wodurch ein gleichwertiges Schutzniveau wie bei der Verwendung digitaler Signaturen auf Basis eines qualifizierten Zertifikats gewährleistet werden kann (§ 4 Abs. 2 GTelV).

Nun soll die Frage erörtert werden, ob die bei einem GDA in den Krankengeschichten erhobenen Daten auch zu Zwecken der medizinischen Forschung verwendet werden dürfen.

Jedenfalls ist dies der Fall, wenn der Betroffene dafür seine explizite Zustimmung erteilt hat. Der OGH fordert jedoch für eine rechtswirksame Einwilligung über die Anforderungen des § 4 Z. 14 DSG hinaus, dass der Patient zuvor sowohl über die verarbeiteten Datenarten als auch über den genauen Zweck der Datenverarbeitung informiert und aufgeklärt worden ist¹⁹ . Ein davon abweichender oder darüber hinausgehender Zweck ist nicht von einer derartigen Einwilligung umfasst, sofern dieser weitere Zweck im Zuge der Einwilligungserklärung nicht ausdrücklich genannt wurde.²⁰  Die Weiterverwendung in indirekt personenbezogener oder anonymer Form ist aber auch bei einem Widerruf der Zustimmung des Patienten hinsichtlich der Verwendung seiner Gesundheitsdaten zulässig.²¹

Doch auch ohne konkrete Einwilligung des Patienten sehen die §§ 6 Abs. 1 Z. 2, 9 Z. 10 und 46 DSG vor, dass bereits für einen bestimmten Zweck bei einem Auftraggeber zulässiger Weise verarbeitete Daten auch für wissenschaftliche Zwecke weiterverwendet werden dürfen, sofern diese kein personenbezogenes Ergebnis zum Ziel haben. Werden die zu anderen zulässigen Zwecken ermittelten Daten von demselben GDA zu Forschungszwecken verwendet, ist eine solche Verwendung sogar in direkt personenbezogener Form zulässig (§ 46 Abs. 1 Z 2 DSG). Dennoch ist der direkte Personenbezug in der Folge beim GDA durch Herstellung eines indirekten Personenbezugs oder durch Anonymisierung gänzlich zu entfernen, wenn mit zumindest indirekt personenbezogenen Daten das Auslangen gefunden werden kann (§ 46 Abs. 5 DSG). Werden Daten jedoch an einen anderen Auftraggeber zu Forschungszwecken übermittelt, ist dies lediglich in indirekt personenbezogener²² oder anonymisierter Form²³ zulässig.

Eine Pflicht zur Information der betroffenen Patienten bezüglich der Durchführung von Studien mit deren Behandlungsdaten ist gem. § 24 Abs. 3 Z 3 DSG dann nicht gegeben, wenn dies in Hinblick auf dieBeeinträchtigung der Betroffenenrechte einerseits und der Kosten der Information aller Betroffenen andererseits einen unverhältnismäßigen Aufwand erfordert.

Zu prüfen ist bei derartigen Forschungsvorhaben auf Basis bestehender Datenbestände weiter auch, ob es sich dabei um eine nicht-interventionelle Studie gem. § 2a Abs. 3 Arzneimittelgesetz handelt und daher die Verordnung über die Meldepflicht für nicht-interventionelle Studien (BGBl. II Nr. 180/2010) anwendbar ist.

Dadurch, dass in der Datenbank des SaaS-Providers die Patientendaten mehrerer bzw. einer Vielzahl von GDA in einer einheitlichen Datenbank gespeichert werden können, entsteht dort im Laufe der Zeit ein umfassender für die medizinische Forschung und den damit verbundenen medizinischen Fortschritt höchst wertvoller Datenbestand.

Dieser Datenbestand birgt insofern ein enormes Potential für die medizinische Forschung, da dadurch eine multizentrisch homogene Datenbasis existiert, die eine wertvolle Grundgesamtheit für aussagekräftige statistische Auswertungen bilden kann. Kommt bei mehreren GDA ein und dieselbe Software als SaaS-Lösung zum Einsatz, so weist die Datenbasis beim Servicebetreiber somit auch eine außerordentliche Homogenität auf, die für statistische Auswertungen notwendig ist. Die üblicherweise bei einer (zulässigen) Zusammenführung von Datenbeständen unterschiedlicher GDA auftretende Heterogenität kann so vermieden werden. Auf Grund der langen gesetzlich vorgeschriebenen Archivierungsfristen steht beim SaaS-Provider weiters ein Datenbestand zur Verfügung, welcher im Gegensatz zu Forschungsvorhaben, die eine eigenständige Datenerhebung erfordern, auch verlässliche Langzeitstudien ermöglicht. Weiters ist so auch eine einfache Analyse etwaiger Begleiterkrankungen und Wechselwirkungen möglich, was z.B. bei klinischen Studien auf Grund der strengen Selektionskriterien für Probanden oftmals nicht möglich ist. Dasselbe gilt für klinische Prüfungen im Zuge von Zulassungsverfahren, da in der Regel auf Grund der strengen Selektionskriterien ausschließlich die Wirksamkeit des zuzulassenden Prüfpräparates getestet wird. Da eine Datenauswertung für statistische Analysen oder Forschungsvorhaben lediglich auf Basis solcher Daten erfolgt, welche ohnedies im Zuge von Behandlungsverläufen entstehen, bedarf es im Gegensatz zu randomisiert klinischen Prüfungen keiner Kontrollgruppe. Somit erhält jeder Patient – im Unterschied zu einer Zuteilung in eine Kontrollgruppe – auch die optimale Behandlung.

Sollen nun bestimmte Datenbestände mehrerer GDA, die allesamt bei demselben SaaS-Provider gespeichert sind, mit deren Zustimmung einem bestimmten Auftraggeber zur Durchführung eines Forschungsvorhabens zur Verfügung gestellt werden, so darf dies selbstverständlich nicht auf beliebige Art und Weise erfolgen und eine solche Datenweitergabe auch nicht im Ermessen des Providers liegen, da dieser ansonsten ebenfalls als Auftraggeber zu qualifizieren wäre. Es sind daher in den Dienstleisterverträgen jedenfalls entsprechende Vereinbarungen aufzunehmen, ob und unter welchen Voraussetzungen welche Daten bestimmter GDA bestimmten anderen Auftraggebern für Forschungsvorhaben zur Verfügung gestellt werden dürfen. Jeder GDA bleibt hinsichtlich «seines» Datenbestandes Auftraggeber und hat daher auch dafür Sorge zu tragen, dass Patientendaten nur in seinem Auftrag und in gesetzlich zulässiger Art und Weise (ggf. durch den SaaS-Betreiber in deren Auftrag) für Forschungsvorhaben zur Verfügung gestellt werden. Die konkrete Beurteilung und Herstellung der datenschutzrechtlichen Konformität muss jedoch im Einzelfall anhand der vorliegenden Umstände, Gegebenheiten und Intention der Forschungsvorhaben erfolgen.

Darüber hinaus darf nicht für jedes Forschungsvorhaben beliebig der gesamte Datenbestand zur Verfügung gestellt werden, sondern lediglich in jenem verhältnismäßigen Umfang, als dies für den Zweck des Forschungsvorhabens notwendig und wesentlich ist (§§ 7 Abs. 3 i.V.m. 6 Abs. 1 Z 2 und 3 DSG). Weiters stellt diese Zurverfügungstellung sowohl bezüglich des «eigenen» Datenbestandes als auch dessen aller anderen involvierten GDA eine Datenübermittlung an den forschenden Auftraggeber dar, die nur unter den Voraussetzungen des § 7 Abs. 2 i.V.m. §§ 9 und 46 DSG zulässig ist. Im konkreten Fall wäre beispielsweise die informierte Einwilligung des Patienten ein gangbarer Weg. Eine andere dem Geheimhaltungsinteresse entsprechende Lösung könnte sein, dass der Datenbestand ausschließlich in anonymisierter Form für die Forschung zur Verfügung gestellt wird. Da gänzlich anonymisierte Daten nicht mehr den Regelungen des DSG unterliegen (§ 1 Abs. 1 DSG), besteht hinsichtlich deren Weitergabe kein rechtliches Hindernis. Jedoch ist zu beachten, dass der anonymisierte Datenbestand eine ausreichend hohek-Anonymität aufweisen muss, sodass auch in bestimmten Konstellationen kein Rückschluss auf Einzelpersonen möglich ist, oder dass Daten, die das Risiko einer möglichen Identifikation in sich bergen, gänzlich von der Weiterverwendung ausgeschlossen werden.

Seit der Änderung des Medizinproduktegesetzes und des Arzneimittelgesetzes (BGBl. I. 143/2009)²⁴ , die mit 21. 3. 2010 in Kraft trat, ist nun auch Software an sich von den Regelungen des Medizinproduktegesetzes umfasst (MPG). Seither ist Software gleichwertig neben den «herkömmlichen» Medizinprodukten gelistet und auch dann als Medizinprodukt, wenn sie eigenständig und nicht bloß als integrierter Bestandteil eines physischen Medizinprodukts (z.B. Beatmungsgerät, EKG-Schreiber) zum Einsatz kommt. Das bedeutet, dass nun auch medizinische Software, die von SaaS-Providern über das Internet bereitgestellt wird, den Regelungen des MPG unterliegen kann, wenn die Voraussetzungen des § 2 Abs. 1 MPG erfüllt sind. Dies ist insbesondere dann der Fall, wenn die Software vom Hersteller speziell zur Anwendung für diagnostische oder therapeutische Zwecke am Menschen und u.a. zum Zweck der Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten oder ggf. Verletzungen bestimmt ist.

Die Entscheidung, ob die von einem Hersteller bereitgestellte Software als Medizinprodukt einzustufen ist oder nicht, ist anhand der Kriterien des § 2 Abs. 1 MPG von diesem selbst zu treffen. Diese Kriterien sind aber sehr allgemein gehalten, was zu einem nicht unwesentlichen Risiko einer Fehlentscheidung und folglich zu nicht unerheblicher Rechtsunsicherheit führt. Unterstützung bei der Entscheidung kann die Empfehlung derCoordination of Notified Bodies Medical Devices «Software and Medical Devices» (NB-MED/2.2/Rec4²⁵ ) bieten. Entsprechend dieser Empfehlung ist Software dann als Medizinprodukt anzusehen, wenn eine oder mehrere der folgenden Bedingungen erfüllt sind:

a)	Der explizite Zweck des Softwareprodukts ist es, in einem (physischen) Medizinprodukt zum Einsatz zu kommen.
b)	Das Softwareprodukt ist dafür bestimmt, die Funktionsweise eines (physischen) Medizinprodukts zu steuern oder zu beeinflussen.
c)	Das Softwareprodukt dient dazu, die von einem Medizinprodukt generierten Daten zu Diagnose- und Überwachungszwecken zu analysieren.
d)	Das Softwareprodukt dient dazu, die körperliche und geistige Verfassung eines Patienten zu diagnostizieren oder eine körperliche und geistige Krankheit zu behandeln.

Erfüllt das Softwareprodukt keine dieser Bedingungen, ist es nicht als Medizinprodukt zu qualifizieren, wodurch auch die entsprechenden Regelungen des MPG nicht zur Anwendung kommen. Die Empfehlung nennt beispielsweise folgende Softwareprodukte, die nicht vom Geltungsbereich der Medizinprodukterichtlinie (bzw. folglich vom MPG) umfasst sind: Software zur administrativen Verwaltung von Patienten, Schulungssoftware oder Tools zur Unterstützung des Designs und der Entwicklung medizinischer Software.²⁶

Im zweiten Schritt muss das Medizinprodukt in eine bestimmte Risikoklasse (I, IIa, IIb, III) entsprechend der MP-RL eingeordnet werden. Abhängig davon ergeben sich die für eine zulässige CE-Kennzeichnung zu erfüllenden Voraussetzungen. Medizinprodukte dürfen nur dann in Verkehr gebracht oder in Betrieb genommen werden, wenn sie entsprechend der relevanten Vorschriften mit der CE-Kennzeichnung versehen sind. Abhängig von der Risikoklasse ergibt sich die Art des zu durchlaufenden Verfahrens bezüglich der Konformitätsbewertung (§§ 27 ff. MPG)²⁷ . Auch die Zuordnung zu Risikoklassen stellt sich in manchen Fällen für den Hersteller nicht eindeutig dar.

Um diesem Entscheidungsrisiko der Hersteller zu begegnen, kann beim Bundesamt für Sicherheit im Gesundheitswesen vom Hersteller die Durchführung eines Feststellungsverfahrens gem. § 5a MPG beantragt werden, in welchem über die Einstufung, ob ein Softwareprodukt als Medizinprodukt einzustufen ist oder nicht und dessen und Klassifizierung entschieden wird..

Aigner, G. (Hrsg.), Handbuch Medizinrecht für die Praxis, Manz Verlag, Wien (Grundwerk 2003).
Birk, D., Wegener, C., Über den Wolken: Cloud Computing im Überblick. In: DuD 9/2010, S. 641 ff (2010).
Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. , Marktzulassung und CE-Kennzeichnungspflicht von Produkten der ITK- und Unterhaltungselektronik-Industrie – Leitfaden,www.bitkom.org/de/publikationen/38337_65745.aspx aufgerufen 4. Januar 2011 (2010).
Drobesch, H., Grosinger, W., Das neue österreichische Datenschutzgesetz, Juridica Verlag, Wien (2000).
GC-impuls , Das ist NEU: Software als Medizinprodukt, 1/2010, S. 1 f (2010).
Graf, W. (Hersg.), Datenschutzrecht im Überblick2, Facultas Verlag, Wien (2010).
Hönel, A, Raschauer, N., Wessely, W., Datenschutzrechtliche Fragestellungen im Zusammenhang mit klinischen Prüfungen. In: RdM 2006, 106 (2006).
Jahnel, D., Handbuch Datenschutzrecht, Sramek Verlag Wien (2010).
Knyrim, R., Siegel, V., Autenberger, S., Datenschutz und Datenrettung beim Outsourcing. In: ecolex 4/2004, S. 413 (2004).
Laga, G. (Hersg.), E-Commerce-Gesetz : Praxiskommentar, LexisNexis-Verlag ARD Orac, Wien, (2007).
Pollirer, H., Weiss, E., Knyrim, R. , Datenschutzgesetz 2000 : (DSG 2000), Manz Verlag, Wien (2010).
Weichert, T., Cloud Computing und Datenschutz. In: DuD 10/2010, S. 679 ff (2010).

---

Bernhard Horn, Projektassistent, Research Industrial Systems IT-Engineering (RISE) GmbH, Am Concorde Park F, 2320 Schwechat, AT,bernhard.horn@rise-world.com

Thomas Grechenig, Universitätsprofessor, Leiter der Forschungsgruppe INSO der TU Wien, Wiedner Hauptstraße 76/2/2, 1040 Wien, AT,thomas.grechenig@inso.tuwien.ac.at

---