Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser...

19
Datenschutz in der medizinischen Softwareentwicklung MEDCONF 2013 München Referent: Rechtsanwalt Thilo Märtin

Transcript of Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser...

Page 1: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Datenschutz in der medizinischenSoftwareentwicklung

MEDCONF 2013 München

Referent: Rechtsanwalt Thilo Märtin

Page 2: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Zur Person:

Thilo Märtin

Rechtsanwalt und Geschäftsführer der

Thilo Märtin & Collegen Rechtsanwalts GmbH i.Gr., Nürnberg.

Seit neun Jahren tätig als Datenschutzberater für mittelständische Unternehmen und Konzerne.

Als behördlich bestellter Datenschutz-Sachverständiger bereitet er IT-Produkte auf das Datenschutzgütesiegel des Unabhängigen Landeszentrums für Datenschutz Schleswig-Holstein vor.

Tätig als Autor für den Haufe Verlag: datenschutzrechtliche Lösungen für Personalabteilungen im „Haufe Personal Office“ und allgemein für „Lexware“.

Page 3: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Überblick

Was schützt der Datenschützer?

Privacy by Design – Privacy by Default

Softwareentwicklung und gesetzliche Anforderungen

Page 4: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Was schützt der Datenschützer? (1)

Bundesdatenschutzgesetz (BDSG):

„§ 1: Zweck dieses Gesetzes ist es, den Einzelnen davor zu schützen,

dass er durch den Umgang mit seinen personenbezogenen Daten in

seinem Persönlichkeitsrecht beeinträchtigt wird.“

Jedermann

Internet

Beruf

Familie

Freunde

ich

Ich habe das

Recht,

zu wissen,

wer was über

mich weiß!

Page 5: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Was schützt der Datenschützer? (2)

Was schützen die Datenschützer eigentlich?

Begriffe:

Personenbezogene Daten - pbD

„Einzelangaben über

persönliche oder sachliche Verhältnisse einer

bestimmten oder bestimmbaren natürlichen Person.“

Bestimmbarkeit:

wenn eine

einzelne Person

durch die Daten

identifiziert

werden kann.

BEISPIELE:

Name, Geburtsdatum,

Geschlecht, Geburtsort,

IP-Adressen,

Datensatz-IDs,

Logdaten mit User-Angaben,

Emailadressen,

PC-Bezeichnung an festen

Arbeitsplätzen

Page 6: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

6

Datensparsamkeit und Zweckbindung - § 3a BDSG

„Die Verarbeitung […] personenbezogener Daten und die Auswahl und Gestaltung von Datenverarbeitungssystemen sind an dem Ziel auszurichten, so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen.

Insbesondere sind personenbezogene Daten zu anonymisieren oder zu pseudonymisieren, soweit dies nach dem Verwendungszweck möglich ist

und keinen im Verhältnis zu dem angestrebten Schutzzweck unverhältnismäßigen Aufwand erfordert.“

Was schützt der Datenschützer? (3)

Page 7: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Privacy by Design – Privacy by Default (1)

Privacy by Design

Definition: Methode zur Verringerung des für den Datenschutz in einem Datenverarbeitungssystem immanent liegenden Gefahrenpotentials durch das Zusammenwirken proaktiver Technikgestaltung und organisatorischer Vorkehrungen (vgl. Spiekermann, The Challenges of Privacy-by-Design, erscheinend in CACM 2012)

Vgl. § 3a BDSG: „DV-Systeme sind an dem Ziel auszurichten, so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen“

Ziel ist es, Datenschutzfunktionen nicht nachträglich „anzuheften“,

sondern frühzeitig durch technische Berücksichtigung datenschutzrechtlicher Prinzipien das Risiko künftiger Vorfälle, die aus dem System heraus kommen, zu minimieren.

Page 8: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Privacy by Design – Privacy by Default (2)

Privacy by Design (2)

Vorteile:

Reduktion datenschutzrechtlicher Risiken

Vermeidung kostspieliger Modifikationen nach Fertigstellung des Produktes: Bsp. Vernetzung von Ärzten in einem Netzwerk: Wenn der IT-Dienstleister bei der Wartung der Datenbank die Namen der Patienten sehen kann, ist dies bereits ein Geheimnisbruch: Das Produkt ist nicht datenschutzkonform und muss z.B. für ein Gütesiegel angepasst werden.

Sinn des Privacy by Design ist: nur mit gesetzlichen Regelungen ist ein Datenschutz heutzutage nicht mehr zu gewährleisten. Ein Eingriff bereits in die Technik-Entwicklung ist notwendig (geworden).

Entwickler erkennen die Vorgabe des § 3a BDSG als relevant für die Entwicklung von Software, insbesondere im sensiblen medizinischen Umfeld und richten selbständig Produkte danach aus.

Page 9: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Privacy by Design – Privacy by Default (3)

Privacy by Default (1)

Standardisiertes, systemseitiges Einrichten datensparsamer Grundeinstellungen in Applikationen mit dem Ziel, die Erhebung, Verarbeitung und Weitergabe personenbezogener Daten von Beginn der Datenverarbeitung an auf das erforderliche Mindestmaß zu begrenzen.

Es wird also nicht von Anfang an alles erhoben an Daten was geht, sondern genau das Gegenteil: Die Anwendung wird „by default“ datensparsam eingestellt und erst nach Entscheidung durch den Betroffenen werden mehr Daten erhoben.

Relevanz im medizinischen Umfeld: Der Patient hat das Recht zu entscheiden, welche Personen davon wissen, dass er bei seinem Arzt vorstellig wird. Der Arzt darf schon diesen Fakt auch nicht einem anderen Arzt offenbaren.

Anwendungen dürfen die Daten also nicht einfach anderen Institutionen (Krankenhäusern, Vor-Ort-Nurses, Hausärzten, Physiotherapeuten) zur Verfügung stellen, wenn der Patient nicht vorher hierin eingewilligt hat.

Stellt die Anwendung die Patienten-Stammdaten jedoch gleich nach Eingabe ins System diesen Stellen ohne Einwilligung zur Verfügung liegt ein Geheimnisbruch vor.

Page 10: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Privacy by Design – Privacy by Default (4)

Privacy by Default (2)

Privacy by Default kann damit als Teilaspekt des Privacy by Design gesehen werden.

Hauptmerkmal von privacy by default-Einstellungen ist die umfassende Datenhoheit des Betroffenen sowie die damit einhergehende Gewähr, dass personenbezogenen Daten ausschließlich nach vorangegangener aktiver Einwilligung veröffentlicht und nutzbar gemacht werden können.

Eine bewusste Entscheidung des Betroffenen wird notwendig – sogenanntes „opt in“.

Der im Jahr 2011 vorgestellte Gesetzentwurf des Bundesrates, der ein verpflichtendes privacyby default für Anbieter von Telemedien (Internet) vorsieht, wurde durch die Regierungskoalition von CDU/CSU und FDP nicht weiterverfolgt. (BT-Drs. 17/6765, § 13a TMG-neu)

Europäische Datenschutz-Grundverordnung (EU-DSGVO): geplant für 2014, kommt aber wohl erst 2015 oder 2016 wirkt unmittelbar in allen Ländern der EU sowohl für den öffentlichen wie auch den nicht-öffentlichen Bereich.

EU-DSGVO sieht in Art. 23 eine Regelung vor, die verantwortliche Stellen zur Implementierung von Mechanismen des privacy by design und by default auffordert. Kommission kann zu der Soll-Vorschrift Vorgaben zur Ausgestaltung machen.

Page 11: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

Privacy by Design – Privacy by Default (5)

Diskussion um „Do not track“ im Browser

Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ – Funktion in Browsern (z.B. zuerst im IE10) war zu erwarten:

Das ULD Schleswig Holstein(!) unterstützte Microsoft bei der Auslieferung des IE10 mit der Grundeinstellung, dass ein Signal ausgesendet wurde vom Browser, dass der User nicht über mehrere Seiten verfolgt werden wolle – eine datenschutzfreundliche Grundeinstellung.

ULD: Der Normalfall sollte und müsste die Internetnutzung ohne Profilbildung durch Tracking sein, nicht informationelle Ausbeutung und Fremdbestimmung.

Im World Wide Web Consortium (W3C), das für eine Standardisierung von Techniken im WWW zuständig ist, sei Microsoft insbesondere von Industrievertretern kritisiert worden. Durch die IE10-Voreinstellung wäre für die Nutzenden keine weitere Aktion nötig, um die Aussendung des DNT-Signals zu veranlassen. Die Industrie erwartet Einbrüche bei den Werbeeinnahmen, wenn das DNT-Signal von den Webserver-Betreibern beachtet werden muss.

Akzeptiert würde nur eine Lösung, bei der die Nutzenden aufgefordert werden, eine aktive Entscheidung für oder gegen das Tracking zu treffen.

Federal Trade Commission (FTC) kritisierte, Microsoft würde durch die Voreinstellung die Verbraucher bevormunden.

Vgl

. ZD

, 20

12

, 03

00

8

Page 12: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

12

Softwareentwicklung und gesetzliche Anforderungen (1)

§ 9 BDSG:

Werden personenbezogene Daten automatisiert verarbeitet oder genutzt,

ist die innerbetriebliche Organisation so zu gestalten,

dass sie den besonderen Anforderungen des Datenschutzes gerecht wird.

Zutrittskontrolle – Wer kommt ins Gebäude? – Zutrittskarten und Besucherbuch

Zugangskontrolle – Wer kommt ins Netzwerk? - Accounts und Log-Ins

Zugriffskontrolle – Wer greift auf welche Daten zu? – Berechtigungen

Weitergabekontrolle – Daten versenden

Eingabekontrolle – Wer hat wann welche Daten bearbeitet?

Verfügbarkeitskontrolle - Datensicherung

Zweckbindung – Daten nur für den vorgesehenen Zweck verwenden

Page 13: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

13

Softwareentwicklung und gesetzliche Anforderungen (2)

Zugriffskontrolle – Wer greift auf welche Daten zu? – Berechtigungen

Die Zugriffsberechtigung ist die Befugnis, mit einer bestimmten Menge von Daten in einer

definierten Weise umzugehen. (Berechtigungskonzept)

Es ist Aufgabe bereits in der Entwicklung der Software solche Kontrollmöglichkeiten zur

Verfügung zu stellen.

Die Befugnis kann sich auf eine bestimmte Teilmenge der durch das System zugänglichen

Daten beziehen,

auf bestimmte Programme, bestimmte Verarbeitungsaktivitäten (Lesbar-Machen, Speichern,

Löschen, Übermitteln) oder

auf bestimmte äußerliche Bedingungen (bestimmte Zeiträume, Vorliegen bestimmter

Voraussetzungen).

Page 14: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

14

Softwareentwicklung und gesetzliche Anforderungen (3)

Weitergabekontrolle – Daten versenden an Dritte – Nachvollziehbarkeit

Maßnahmen, damit festgestellt werden kann, an welchen Stellen vorgesehen ist, Daten zu

übermitteln. Verlangt wird also eine Bezeichnung der in Betracht kommenden

Übermittlungsadressaten.

Der Empfänger ist danach so konkret zu bestimmen und einzugrenzen, dass eine eindeutige

Feststellung zur Zulässigkeit getroffen werden kann. Das muss nicht immer namentlich sein!

In telemedizinischen Datennetzen allerdings wird die sogenannte Nicht-Abstreitbarkeit einer

Übermittlung verlangt: D.h. einerseits ist zu gewährleisten, dass der Sender eines

patientenbezogenen Dokuments sicher sein kann, dass das Dokument seinen Empfänger erreicht

hat, und er darf nicht abstreiten können, genau dieses Dokument an genau den Empfänger

gesendet zu haben.

Andererseits muss der Empfänger eines patientenbezogenen Dokuments sicher sein können,

genau dieses Dokument von einem bestimmten Sender empfangen zu haben, und er darf nicht

abstreiten können, genau das Dokument von einem bestimmten Sender empfangen zu haben.

Page 15: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

15

Softwareentwicklung und gesetzliche Anforderungen (4)

Eingabekontrolle – Wer hat wann welche Daten bearbeitet?

§ 9 BDSG: „es ist zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob

und von wem personenbezogenen Daten in Datenverarbeitungssysteme eingegeben, verändert

oder entfernt worden sind“.

Es muss feststellbar sein, ob und von wem die Daten eingegeben wurden.

Es genügt nicht, dass der Personenkreis näher eingeengt wird, von dem die Dateneingabe,

Änderung oder Löschung herrührt. Entscheidend ist vielmehr, dass die Identität dessen, der

bestimmte Daten eingegeben, verändert oder gelöscht hat, feststellbar ist.

Diese Identifizierbarkeit kann auch über weitere Hilfsmittel wie automatisiertes

Anmeldeprotokoll, Schicht- oder Eingangskontrollbücher erreicht werden.

Verhältnismäßigkeit wahren: es ist nicht für jede Datenbank ein umfassender Audit-Trail

notwendig. Maßnahmen sind abzustufen nach Menge und Sensibilität der Daten.

Page 16: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

16

Softwareentwicklung und gesetzliche Anforderungen (5)

Gewährleistung der Zweckbindung – Darf ich das mit den Daten machen?

Neu ins BDSG aufgenommen: Die verantwortliche Stelle hat sicherzustellen, dass zu

unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können.

Ziel der Regelung: die verantwortliche Stelle schon bei der Inbetriebnahme darauf

hinzuweisen, die Systeme so auszulegen, dass personenbezogene Daten, die zu

unterschiedlichen Zwecken erhoben wurden, auch getrennt verarbeitet werden können.

Möglich durch physikalische oder auch logische Trennung (verschiedene Server,

Datenbankinstanzen, Bibliotheken); Trennung z.B. nur durch Nummernkreise schon kritisch.

Prüfen, ob Durchbrechung der Trennung z.B. durch Querys oder externe Anwendungen über

umfassende Schnittstellen möglich ist (z.B. ODBC).

- Beispiele auf der nächsten Folie -

Page 17: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

17

Softwareentwicklung und gesetzliche Anforderungen (6)

Forts. Gewährleistung der Zweckbindung – Darf ich das mit den Daten machen?

Anwendungsbeispiele:

Speicherung von Patientendaten verschiedener Ärzte in einer Datenbank/auf einem Server

Testsysteme und Produktiv-Systeme: Echtdaten dürfen nicht in Testsystemen verwendet

werden

Trennung der Patientendatensätze von den Datensätzen, die mit Data-Mining statistisch

ausgewertet werden: diese sind zuvor zu anonymisieren. (Beispiel: Rezeptdaten in den

Apotheken-RZ)

Beispiele für Maßnahmen in der Zweckbindung:

Trennung der Datensätze durch Speicherung in physikalisch getrennten Datenbanken;

Zugriff auf Datensätze nur über Anwendungen, in der die Logik festlegt wurde;

Unterschiedliche Verschlüsselung von Datensätzen zur Abgrenzung der Zweckbindungen;

Versehen der Datensätze mit Attributs-Signaturen zur Festlegung der Zweckbindung. Der

Zugriff darf nur über Anwendungen erfolgen, die keine Änderungen der Zweckbindung

garantieren und für die Verarbeitung zugelassen sind;

Festlegung von Rollen in einem Informationssystem: Administrator, Revisor, Benutzer etc.;

Page 18: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

18

Softwareentwicklung und gesetzliche Anforderungen (6)

Was tut der Datenschützer in der Softwareentwicklung?

Funktionalität verstehen und Datenflüsse abstrahieren:

Woher kommen die personenbezogenen Daten?

Was passiert in der Anwendung damit?

Wohin werden sie exportiert bzw. verfügbar gemacht?

Bewertung der geplanten Anwendung: wie kritisch sind die Daten? Über welche

Datenmengen wird gesprochen?

Pfichten- und Lastenheft prüfen und im Gespräch mit dem Entwickler

nachvollziehen, welche Verarbeitungen geplant sind

Kritische Stellen aufzeigen und in enger Zusammenarbeit feedbacken und

anpassen (angenehm bei agiler Entwicklung)

Page 19: Datenschutz in der medizinischen Softwareentwicklung · Diskussion um „Do not track“ im Browser Diskussion in der Wirtschaft für die an sich unbrauchbare „do not track“ –Funktion

VIELEN DANK FÜR DIE

AUFMERKSAMKEIT!

NOCH FRAGEN?

Thilo MärtinRechtsanwalt

Kleestr. 21-2390461 Nürnberg

Tel.: +49 911 2398-5401Fax: +49 911 2398-5419

daten-schuetzen.com