{martin.degeling, jan.nierhoff}@ruhr-uni-bochum.de

1. Entwicklung einer Webanwendung im Rahmen
eines Forschungsprojekts zur Unterstützung von
Reflexion am Arbeitplatz.

2. Integration von Prinzipien des
Privacy-by-design in den Entwicklungsprozess.

3. Darstellung der Ergebnisse

Überblick

Kontext

Projekt MIRROR
Reflective Learning @ Work
(www.mirror-project.eu)

Kollaborative Reflexion?

Die gemeinschaftliche Entwicklung (und Umsetzung)
von Ideen zur Verbesserung von Arbeitsprozessen
aus konkreten Erfahrungen heraus.

Reflection Model

nach (Boud 1980)

Collaborative Reflection Support

nach (Prilla, Degeling, Herrmann 2012)

Ziel der Anwendung

Unterstützung eines kollaborativen
Reflexionsprozesses insbesondere beim

•  Dokumentatieren und Teilen
   von Erfahrungen
•  Festhalten und Kommunizieren von
   Ergebnissen eines Reflexionsprozesses
  

Die Monopolisierung der kollaborativen Reflexion
innerhalb eines technischen Systems ist nicht das
Ziel der Anwendung

!Ziel der Anwendung

Documented
Conversation

"[...] therapy finished. Again relapse,
palliative therapy. Prepared [relatives] for
begin of home care, asked to seek profes-
sional support for care. Talk was very diff-
icult, parts were not received or blocked out.”

“[From my experience] especially in the first
talk it is important to take some time”

“Problem: Conversation held alone.
It should be known that a senior physician
can be asked for support”

Authors
comment

Other users
comment

Result

“[Relative] conveys the feeling it is our fault.
(…) Hears for the first time that [patient] is
going to die”

Wichtig

Der sozio-technische Prozess der kollaborativen
Reflexion benötigt nicht nur technische
sondern auch organisatorische Unterstützung

Der Entwicklungsprozess

Vorgehen

Ideenentwicklung mit dem
Praxispartner

•  Ärztinnen und Ärzte einer
   neurorologischen akut Station
•  Pfleger/innen eines Heims für
   Demenzkranke
  

Ziel: Unterstützung bei der Reflexion
von Angehörigengesprächen

Zur Erhebung von Datenschutzawareness, -praxis und
Vertrauensverhältnis zu Kolleg/innen
und Organisation

Fragebogen

Ergbnisse:  eine Auswahl

Ausgefüllt von 134 (110) potentielle User/innen

• Hohe Awareness für Datenschutzfragen
  im Gesundheitwesen
  
  

• nicht ganz so hohe Datenschutzpraxis
  
  
• Vertrauen in Kolleg_innen und Organisation bei
  gleichzeitiger Sorge um Missbrauch

Identifizierte Rollen
und Probleme aus
Datenschutzsicht

Schwerpunkte

User

• Preisgabe persönlicher Erfahrungen
  

• Leistungs- und Verhaltenskontrolle
  
• Sorge um Missbrauch
  
  

Organisation

•  Verantwortlichkeit (rechtlich)

Dritte

• Als die über die gesprochen wird
  (ggf. geht es um Gesundheitsdaten)
  

Privacy by design

Abstrakte Anforderungen zur
Datenschutzfreundlichen
Technikentwicklung

Cavoukian (2009)

"The 7 Foundational Principles"

1. Proactive not Reactive

2. Privacy as the Default   

3. Privacy Embedded into Design     

4. Full Functionality

5. End-to-End Lifecycle Protection

6. Visibility and Transparency

7. Respect for User Privacy

Langheinrich (2001)

Aus dem Kontext der Diskussion von ubiquitous computing

1. Notice

2. Consent

3. Anonymity and Pseudonymity

4. Proximity

5. Locality

6. Security

7. Access and Recourse

Schaar (2010)

1. Data minimization

2. Controllability   

3. Transparency

4. Data confidentiality

5. Data quality

6. Possibility of segregation

Zusätzliche Stakeholder

Bei der Priorisierung waren insbesondere beteiligt:

• Der Betriebsrat
  
• Der Datenschutzbeauftragte der Klinik
• Die IT-Abteilung
• Projektleiter
  

Für uns relevante PbD Ziele

1. Datenminimierung
2. Einwilligung
3. Privacy by Default
4. Awareness und Transparenz
5. Anonymität und Pseudonymität
6. Löschung

Beispiele in der Umsetzung

Datenminimierung

Username/Passwort
Registrierungsschlüssel

Kleine Gruppen
Intensive Kommunikation
außerhalb der Anwendung

Einwilligung

Schriftliche, persönliche Einwilligung bei Einführungs-
workshop.
Schulung und Diskussion über
die Anwendung

Default Einstellungen

Eingetragene Dokumentationen
sind erstmal nur für den/die Autor/in sichtbar.

Awareness und Transparenz

•  separate Listen für eigene Beiträge und die Andere

•  sichtbarmachung der Anzahl

•  genauen Listen der User mit Leserechten
  

Anonyme und Pseudonyme
Nutzung ermöglichen

• Speichern von Dokumentationen
  und Kommentaren anonym* möglich
  (*Autor/in nur für andere User nicht sichtbar)
  

• Pseudonyme Nutzung erlaubt

Löschung

• Zugriffe können zurückgezogen werden

• Autor/innen können einzelne Beiträge löschen

• Optional: Archivierung oder Löschung

Konflikte

• leichte Nutzbarkeit vs. privacy by default
  
  
• Vorort Installation vs. Hosting
  
  

• Offene Eingabefelder vs. betroffene Dritte
  
  

• implizit und informierte Einwilligung vs. TL;DR
  
  
• Sinkende Aufmerksamkeit bei Projektverantwortlichen
  

Offene Punkte - für uns

•  Security testing/hardening
   
  
•  Schutz Dritter momentan nur auf
  organisatorischer Ebene (Namensanalyse; Melde-
  system)
  
  
•  Data Segregation
  

Offene Punkte - PbD

• Integration in Nutzer-zentrierte
  Vorgehensmodelle
  
  
• Schulungen für Entwickler/innen (Privacy Patterns)
  

Fragen, Anmerkungen?