SEMINAR

FÜR WIRTSCHAFTSINFORMATIK

UND SYSTEMENTWICKLUNG Prof. Dr. Werner Mellis

Hauptseminar Wirtschaftsinformatik

im Sommersemester 2012

Thema Nr. 4

Crowdsourcing zur Verbesserung medizinischer Daten

vorgelegt von:

Blesik, Till

1

Inhaltsverzeichnis

1. Problemstellung und Zielsetzung .................................................................................. 2

2. Medizinische Daten ...................................................................................................... 5

2.1 Ausprägungen und Definitionen .............................................................................. 5

2.2 Vorhandene Systeme und Datenbasis ...................................................................... 7

3. Crowdsourcing .............................................................................................................. 8

3.1 Charakteristiken ..................................................................................................... 10

3.1.1 Die Crowd ..................................................................................................... 10

3.1.2 Der Prozess ................................................................................................... 11

3.2 Systemtypen ........................................................................................................... 12

4. Anforderungskatalog ................................................................................................... 13

4.1 Anforderungen ....................................................................................................... 13

4.1.1 Input-Qualitätssicherung ............................................................................... 14

4.1.2 Desidentifikation ........................................................................................... 14

4.1.3 Interoperabilität ............................................................................................. 15

4.1.4 Ergebnis-Qualitätssicherung ......................................................................... 15

4.2 Anforderungsframework ........................................................................................ 16

5. Systemkonzeption ....................................................................................................... 17

5.1 Import ..................................................................................................................... 17

5.2 Aufbereitung .......................................................................................................... 18

5.3 Transformation und Anreicherung ......................................................................... 20

5.4 Qualitätssicherung .................................................................................................. 21

6. Fazit und Ausblick ...................................................................................................... 23

Literaturverzeichnis ......................................................................................................... 24

Anhang ............................................................................................................................. 28

2

Abkürzungsverzeichnis

API Application Programming Interface

DNA Desoxyribonukleinsäure

EG Europäische Gemeinschaft

EGA Elektronische Gesundheitsakte

EHR electronic health record

EKA Elektronische Krankenakte

EMR electronic medical record

EPA elektronische Patientenakte

GWAP games with a purpose

HIPAA Health Insurance Portability and Accountability Act

HIT Human Intelligence Tasks

HL7 Health Level Seven

ISO International Organization for Standardization

KBV Kassenärztlichen Bundesvereinigung

MTurk Mechanical Turk

PHR personal health record

TR Technical Report

xDT xDatentransfer

XML Extensible Markup Language

3

Abbildungsverzeichnis

Abb. 3-1: Crowdsourcing .................................................................................................. 9

Abb. 5-1: Prozessablauf des Systems .............................................................................. 17

Abb. 5-2: Importwege für Patientendaten ....................................................................... 18

Abb. 5-3: Schema für die Aufbereitung der Patientendaten ............................................ 19

Abb. 5-4: Transformation und Anreicherung der Daten ................................................. 21

Abb. 5-5: Maßnahmen zur Qualitätssicherung ................................................................ 22

4

1. Problemstellung und Zielsetzung

Immer mehr eHealth-Systeme sind auf Patienten ausgerichtet und werden nicht mehr

nur zur Leistungserbringung entwickelt.1 Die vorhandenen medizinischen Daten sind

für Interessierte ohne medizinische Vorbildung oft nicht verständlich, selbst

Informationen, die Patienten direkt von Medizinern bekommen, werden häufig falsch

interpretiert oder nicht verstanden.2 Eine Umwandlung der Daten in eine für Laien

verständliche Darstellung durch die zuständigen Ärzte wäre jedoch zu aufwändig und

teuer. Eine verständliche Darstellung ihrer Daten würde den Krankenhäusern Zeit und

Kosten ersparen und könnte Fehlverhalten der Patienten bei Umsetzung der

Behandlungsanweisungen vermeiden, die aus Fehlinterpretation von Informationen

resultieren. Zusätzlich wäre es für Patienten möglich, zeitnäher auf ermittelte Werte und

Diagnosen zu reagieren als dies der Fall ist, wenn auf einen Arzttermin gewartet werden

muss. Die Behandlung könnte außerdem dadurch verbessert werden, dass der Patient

jederzeit korrekte Verhaltensempfehlungen und beispielsweise Informationen über

Dosierungen für die medikamentöse Behandlung abrufen könnte, statt sich auf seine

Erinnerung verlassen zu müssen.

Die Überführung von medizinischen Daten in ein verständliches Format, kann als eine

Art Übersetzung gesehen werden. Crowdsourcing ermöglicht die Beschaffung günstiger

Arbeitskraft und hat sich als effiziente und qualitativ hochwertige Methode für

Übersetzungen bewährt.3,4 Als Crowdsourcing bezeichnet man das Auslagern von

Aktivitäten, die zuvor durch Angestellte ausgeführt wurden, in eine breite Masse von

Menschen.5 Es ist aber noch nicht geklärt, ob und wie Crowdsourcing genutzt werden

kann, um medizinische Daten in eine für Laien verständliche Darstellung zu

transformieren. Die vorhandenen Daten sind in unterschiedlichsten Systemen

gespeichert,6 teilweise nur als Freitext ohne semantische Struktur vorhanden,7 und

1 Vgl. Rusu u. a. (2010), S. 3–4. 2 Vgl. Barry D. Weiss (2009), S. 6. 3 Vgl. Zaidan, Callison-Burch (2011), S. 1228. 4 Vgl. Matteo Negri, Yashar Mehdad (2010), S. 215. 5 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 192. 6 Vgl. Caligtan, Dykes (2011), S. 219.

5

können strikten Datenschutzbestimmungen unterliegen8. Es existiert kein Konzept, das

die Probleme und Voraussetzungen für ein System zur Transformation und

Anreicherung medizinischer Daten mittels Crowdsourcing beschreibt. Ein

Rahmenkonzept würde die Erstellung eines entsprechenden Systems ermöglichen und

wäre daher eine Hilfe für datenlastige patientenzentrierte eHealth Systeme.

Ziel dieser Arbeit ist die Definition eines Konzepts, das die Herausforderungen und

möglichen Vorgehensweisen bei der Nutzung von Crowdsourcing zur Transformation

und Anreicherung medizinischer Daten beschreibt.

2. Medizinische Daten

Der Begriff „medizinische Daten“ ist sehr umfassend und als solcher nicht scharf

definiert. In den Definitionen mehrerer Begriffe aus dem Bereich der (elektronischen)

medizinischen Dokumentation wird jedoch von medizinischen Daten gesprochen.9 Im

Folgenden werden daher die für diese Arbeit relevanten Begriffe beschrieben. Der

Begriff „medizinische Daten“ ist dabei als Abstraktum für verschiedene Informationen

zu verstehen, die medizinische Relevanz haben.

Medizinische Daten können als Basis vieler patientenzentrierter eHealth Systeme

genutzt werden. Übersetzung und Anreicherung dieser Daten stellt einen zentralen

Punkt der vorliegenden Arbeit dar. Der erste Abschnitt dieses Kapitels befasst sich mit

der Definition verschiedener Ausprägungen von medizinischen Daten. Im zweiten

Abschnitt wird ein grober Überblick über aktuell vorhandene Informationssysteme

gegeben und beschrieben, in welcher Form die darin vorhandenen medizinischen Daten

vorliegen.

2.1 Ausprägungen und Definitionen

Traditionell wurden Behandlungsdaten von Patienten auf Papier festgehalten und in

Ordnern, den sogenannten Krankenakten, verwaltet.10 Jedes Institut beziehungsweise

jede Abteilung, die ein Patient zur Behandlung durchlief, legte neue Krankenakten an.11

In die Krankenakten wurden handschriftlich die jeweiligen Testergebnisse, Befunde,

7 Vgl. Häyrinen, Saranto, Nykänen (2008), S. 295. 8 Vgl. Townend (2010), S. 479. 9 Vgl. Prokosch (2010), S. 1. 10 Vgl. Stein (1997), S. 3. 11 Vgl. Dick, Steen, Detmer (1997), S. 47.

6

Beratungsnotizen und Behandlungsanweisungen eingetragen.12 Die Elektronische

Krankenakte (EKA)13 stellt das Äquivalent der klassischen Krankenakte in

medizinischen Informationssystemen dar. Im Folgenden wird die in der englischen

Literatur übliche Bezeichnung electronic medical record (EMR) genutzt. EMRs

werden von der American Medical Association als Aufzeichnung der individuellen

Gesundheitszustands- und Behandlungsgeschichte beschrieben.14 Ein EMR enthält

medizinische Daten einer einzelnen (Krankenhaus)Abteilung15 und ist damit, wie die

klassische Patientenakte, ein lokaler Datensatz, der inkompatibel mit Systemen anderer

Gesundheitsinstitute sein kann16.

Ein EMR ist dabei nur ein spezieller electronic health record (EHR)17. EHR lässt sich

im Deutschen mit elektronische Patientenakte (EPA)18 übersetzen und wird in der

ISO/TR 12773-1 definiert als Speicher von Informationen bezüglich des

Gesundheitszustandes einer behandelten Person, in einer für Computer verarbeitbaren

Form.19 Die Definition von EHR ist entweder sehr allgemein und in der Literatur

werden verschiedene Begriffe als Synonym verwendet oder es ist ein spezieller EHR

Typ gemeint, wie der zuvor beschriebene EMR20.21 Im Gegensatz zum EMR ist ein

EHR nicht an eine Institution gebunden, sondern kann medizinische Daten aus

mehreren Abteilungen oder Instituten enthalten, die ein Patient zur Behandlung

durchlaufen hat.22

Während die meisten EHR Typen leistungserbringergeführt sind, da sie in

verschiedenen Krankenhäusern geführt werden und die Nutzergruppe normalerweise

Anbieter von Gesundheitsdienstleistungen sind, gibt es eine wichtige Form, den

12 Vgl. Dick, Steen, Detmer (1997), S. 47. 13 Vgl. Prokosch (2010), S. 1. 14 Vgl. American Medical Association (2011b), S. 1–2. 15 Vgl. Häyrinen, Saranto, Nykänen (2008), S. 295. 16 Vgl. American Medical Association (2011b), S. 1. 17 Vgl. Häyrinen, Saranto, Nykänen (2008), S. 295. 18 Vgl. Prokosch (2010), S. 1. 19 Vgl. ISO (2009), S. o. A. zitiert nach Caligtan, Dykes (2011), S. 220. 20 Vgl. American Medical Association (2011a), S. 1. 21 Vgl. Kaletsch, Sunyaev (2011), S. 3–4. 22 Vgl. Caligtan, Dykes (2011), S. 220.

7

sogenannten personal health record (PHR), welcher patientenorientiert ist23. Ein PHR

ist definiert als elektronische, universell verfügbare, lebenslange Quelle für

Gesundheitsinformationen.24 Im Deutschen kann ein PHR als elektronische

Gesundheitsakte (EGA)25 bezeichnet werden. Ein besonderes Merkmal der PHR ist,

dass der Patient die absolute Datenhoheit hat, er kann entscheiden, wer welche

Informationen nutzen und hinzufügen darf, er kann eigene Datensätze einfügen und den

PHR über ein Portal nutzen, um mit seinen Ärzten zu kommunizieren.26

Neben den patientenbezogenen medizinischen Daten gibt es noch allgemeine

medizinische Informationen. Als medizinische Informationen werden hier

beispielsweise Dosierungsangaben für Medikamente, Funktionsweise von Organen oder

die Bezeichnung von Knochen und Muskeln im Körper verstanden.

2.2 Vorhandene Systeme und Datenbasis

Die Nutzung von IT-Systemen im Gesundheitssystem nimmt seit Jahren kontinuierlich

zu.27 In diesem Abschnitt werden wesentliche Systeme vorgestellt, die für die

Verwaltung von Patientendaten, die im vorigen Abschnitt 2.1 beschrieben wurden,

genutzt werden.

In einem durchschnittlichen deutschen Krankenhaus werden jährlich etwa 6 Millionen

Dokumente/Datensätze erzeugt28 und es existieren viele verschiedene Systemtypen, die

teils auf einzelne Krankheiten spezialisiert sind29. Es ist nicht Ziel des Abschnittes eine

vollständige Übersicht zu liefern, sondern wichtige Systeme und Standards vorzustellen.

Nimmt man die Anzahl der Installationen als Maßstab, dann waren 2009 folgende

System die größten im US-Markt: Meditech30, Cerner31, McKesson32, Siemens33 und

23 Vgl. Caligtan, Dykes (2011), S. 222. 24 Vgl. ISO (2009), S. o. A. zitiert nach Caligtan, Dykes (2011), S. 220. 25 Vgl. Prokosch (2010), S. 1. 26 Vgl. Caligtan, Dykes (2011), S. 222. 27 Vgl. Ortega Egea, González, Menéndez (2010), S. 541. 28 Vgl. Reinhold (2006), S. 271. 29 Vgl. Häyrinen, Saranto, Nykänen (2008), S. 293. 30 http://www.meditech.de 31 http://www.cerner.com 32 http://www.mckesson.com 33 http://www.medical.siemens.com

8

CPSI34.35 Aufgrund der herausragenden Stellung von Microsoft im IT-Sektor ist noch

HealthVault36 zu nennen, auch Google wagte einen Vorstoß, hat sein Google Health

Programm37 jedoch zum 2.1.2012 eingestellt.

Um den vollen Nutzen aus elektronischen Patientendaten ziehen zu können, ist es nötig

einen effizienten Informationsfluss zwischen den Beteiligten zu schaffen.38 Für den

Datenaustausch existieren verschiedene Standards, von denen hier einige vorgestellt

werden.

xDT beschreibt eine Gruppe von Datenaustauschformaten für Arztpraxen und wird von

der Kassenärztlichen Bundesvereinigung (KBV) verwaltet.39 Bei in Deutschland

niedergelassenen Ärzten, hatte sich xDT als Standard zum Datenaustausch durchgesetzt,

wird mitlerweile aber von „Extensible Markup Language“-basierten Standards (XML)

und Health Level Seven (HL7) in den Hintergrund gedrängt.40 Ein weiterer, und einer

der bekanntesten, Standards ist HL7 Format.41 Einer Studie42, aus dem Jahr 2004,

zufolge, gehört HL7 zu den meistgenutzten Standards. Mit diesen beiden sind nur zwei

der wichtigsten Standards genannt, es existieren noch wesentlich mehr.

3. Crowdsourcing

Der Begriff Crowdsourcing wurde von Outsourcing abgeleitet und erstmals von Jeff

Howe im „Wired“ Magazin genutzt.43 Es existieren diverse Begriffsdefinitionen, Howe

selbst hat mehrere Definitionen verwendet.44 Dabei spricht er entweder sehr allgemein

von einer Rubrik für eine große Anzahl von Aktivitäten oder spezifischer vom

Auslagern von Aktivitäten, die zuvor durch Angestellte ausgeführt wurden, in eine

34 http://www.cpsinet.com/emr 35 Vgl. Modern Healthcare (2011), S. o. A. zitiert nach Caligtan, Dykes (2011), S. 219. 36 http://www.microsoft.com/de-de/healthvault/default.aspx 37 https://health.google.com 38 Vgl. Pedersen, Hasselbring (2004), S. 175. 39 Vgl. Kassenärztliche Bundesvereinigung (24.04.2012), S. 1. 40 Vgl. Kassenärztliche Bundesvereinigung (21.06.2012), S. -2. 41 Vgl. Lin u. a. (2012), S. 1184. 42 Health Information Management and Systems (2004). 43 Vgl. Jeff Howe (2006b), S. 2. 44 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 192–193.

9

breite, undefinierte Masse von Menschen.45 Bei dieser Definition lässt er außer Acht,

dass durch die geringen Kosten auch Aktivitäten durchgeführt werden können, die mit

Angestellten unbezahlbar gewesen wären. Des Weiteren wird die Crowd oft sorgfältig

selektiert und ist keine undefinierte, breite Masse. Auf Basis dieser Kritikpunkte

definieren Anastasiou und Gupta Crowdsourcing im Kontext von Übersetzungen als

Prozess, mit dem Organisationen das Wissen einer externen, geeigneten Community zu

ihrem Vorteil nutzen können, indem sie von geringen Kosten und Mehrsprachigkeit

profitieren.46 Der grobe Ablauf von Crowdsourcing ist in Abb. 3-1 dargestellt: Als

erstes wird eine Aufgabe an die Crowd gegeben, diese löst im zweiten Schritt die

Aufgabe oder Teile der Aufgabe und gibt die Lösung(en) zurück, dafür werden sie, im

dritten Schritt, üblicherweise mit Geld, belohnt. Eine genaue Beschreibung der

einzelnen Elemente des Crowdsourcing und Systemtypen folgt in den nächsten beiden

Unterkapiteln.

Abb. 3-1: Crowdsourcing

Crowdsourcing hat Überschneidungen mit „human computing“, also dem Ansatz

menschliche Verarbeitungsfähigkeiten zu nutzen, um Probleme zu lösen, die Computer

noch nicht lösen können.47 Die Überschneidung betrifft Anwendungen, die als Ersatz

für traditionell von Computern oder Menschen ausgefüllte Rollen fungieren. Eine

Übersetzung ist ein Beispiel für eine Aufgabe, die von Computern durchgeführt werden

kann, wenn Geschwindigkeit und Kosten wichtig sind, oder von Menschen, wenn

Qualität wichtig ist.

45 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 192. 46 Vgl. Anastasiou, Gupta (2011), S. 638. 47 Vgl. zu diesem Absatz Quinn, Bederson (2011), S. 2–3.

10

3.1 Charakteristiken

Das Wort „Crowdsourcing“ ist aus den Bestandteilen „Crowd“ und „Sourcing“

zusammengesetzt.48 Die „Crowd“ ist dabei eine Referenz auf die teilnehmenden

Personen und „Sourcing“ beschreibt die unternommenen Anstrengungen um

Teilnehmer zu finden, zu evaluieren und zu engagieren. Durch Analyse der Literatur

lassen sich 3 Elemente und 8 Charakteristiken des Crowdsourcing identifizieren:

Die Crowd: (1) Wer stellt die Crowd zusammen? (2) Was muss die Crowd

machen? (3) Was bekommt die Crowd als Gegenleistung?

Der Initiator: (4) Wer ist der Initiator? (5) Was bekommt der Initiator als

Ergebnis der Arbeit der Crowd?

Der Prozess: (6) Um welchen Prozesstyp handelt es sich? (7) Welche Art des

Aufrufs wird genutzt? (8) Welches Medium wird genutzt?

Der Focus dieser Arbeit liegt auf dem Entwurf eines Systems und nicht auf der

Einrichtung die dieses System führt, daher werden im Folgenden nur Element 1 „die

Crowd“ und Element 3 „der Prozess“ näher beschrieben.

3.1.1 Die Crowd

Die Zusammenstellung der Crowd (Charakteristik 1) lässt sich in zwei Charakteristiken

unterteilen: die Anzahl der Personen und deren Typologie.49 Die Anzahl der Personen

variiert dabei, abhängig vom Projekt und dem nötigen Aufwand zur Filterung und

Evaluation der Daten.50 Die Zusammenstellung ist ebenfalls abhängig vom Fokus des

jeweiligen Projekts. Es kann dabei grob unterschieden werden zwischen Amateuren, die

bei den meisten Projekten den Großteil der Teilnehmer darstellen, und Profis, die sehr

selten anzutreffen sind.51

Auch bei der Frage nach der Aufgabe der Crowd (Charakteristik 2) finden sich zwei

Ansätze, die sich in der Spezifität ihrer Beschreibung unterscheiden: während der erste

Ansatz ganz allgemein die Bearbeitung von Aufgaben von unterschiedlichem

Schwierigkeitsgrad und Aufwand beschreibt, steht beim zweiten Ansatz die Lösung

48 Vgl. zu diesem Absatz Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 189,191. 49 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 193. 50 Vgl. La Vecchia, Cisternino (2010), S. 426. 51 Vgl. Schenk, Guittard (2011), S. 13–14.

11

eines Problems im Vordergrund.52 Es ist vorteilhaft, wenn die Aufgabe unterteilbar ist

in kleinere, klar definierte Unteraufgaben, die jeweils von Mitgliedern der Crowd

bearbeitet werden können.53

Die Frage nach der Gegenleistung für Mitglieder der Crowd (Charakteristik 3) zielt auf

die Gründe ab, die Personen dazu bewegen an Crowdsourcing Projekten teilzunehmen.

Als Gegenleistung werden hauptsächlich Geld und soziale Wertschätzung genannt.54

Der Aspekt der Motivation liegt nicht im Fokus dieser Arbeit, wichtig ist jedoch, dass

die monetären Gegenleistungen im Normalfall sehr gering sind und Crowdsourcing

daher eine Möglichkeit ist, um aufwändige Übersetzungen in hohem Tempo, aber mit

geringen Kosten zu realisieren.55

3.1.2 Der Prozess

Wie die Wortherkunft nahe legt, wird der Crowdsourcing-Prozess in der Literatur

häufig als Outsourcing typisiert (Charakteristik 6).56 Es finden sich allerdings auch viele

weitere Typisierungen: als Problemlösungsprozess, Produktionsmodel, Geschäfts- oder

Strategiemodell, Arbeitsorganisationsprozess, Kundenintegrationsprozess und offener

Innovationsprozess. Gemeinsam ist, dass es sich um einen online-basierten,

gemeinschaftlichen Prozess zur Lösung von Aufgaben handelt.

Für einen gemeinschaftlichen Prozess muss natürlich eine Gemeinschaft gefunden

werden, dafür gibt es mehrere Varianten (Charakteristik 7). Der Ansatz, möglichst viele

Personen in Form eines offenen Aufrufs zu adressieren, hat sich als relativ erfolgreich

erwiesen.57 Neben einem echten offenen Aufruf kann man auch eine bestimmte

Community adressieren, um dort vorhandenes spezielles Wissen zu nutzen, oder beide

Varianten kombinieren und im Anschluss an einen offenen Aufruf eine

Kontrolle/Selektion durchführen.58

52 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 194. 53 Vgl. Heer, Bostock (2010), S. 205,208,210. 54 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 194–195. 55 Vgl. Anastasiou, Gupta (2011), S. 649. 56 Vgl. zu diesem Absatz Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 196. 57 Vgl. Schenk, Guittard (2011), S. 14. 58 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 196.

12

Das genutzte Medium (Charakteristik 8) ist zweifelsfrei das Internet. Sowohl Jeff

Howe, der Erfinder des Begriffes Crowdsourcing,59 als auch diverse andere Autoren

nehmen in ihren Definitionen Bezug auf das Internet.60

3.2 Systemtypen

Im Web existieren viele Systeme, beispielsweise Mechanical Turk61, Wikipedia62 und

das ESP Game63, die dem Crowdsourcing zugeordnet werden und es gibt ausgefeilte,

mehrdimensionale Ansätze zur Unterscheidung dieser Systeme.64 Im Folgenden werden

zwei Typen kurz skizziert: Plattformen auf denen Aufgaben, sogenannte „Human

Intelligence Tasks“ (HIT), direkt an die Crowd verteilen werden und Systeme, bei

denen die Aufgabe in Spiele integriert wird, sogenannte „Games with a purpose“

(GWAP). Diese beiden Typen werden vorgestellt, da der erste Systemtyp sich für

Übersetzungen eignet65 und der zweite Systemtyp schon mehrfach in der medizinischen

Forschung genutzt wurde66.

Eine populäre Plattform für den Austausch von HITs ist Amazons Mechanical Turk

(MTurk).67 Amazon hat bei der Erstellung von MTurk nicht die Intention gehabt, einen

Marktplatz für HITs zu schaffen, sondern sie wollten Nutzer für das Melden von

Dubletten der Angebotsseiten bezahlen, da diese Aufgabe nicht zufriedenstellend

automatisierbar war.68 Mittlerweile ist es möglich HITs auf MTurk per API

einzustellen, wodurch man ein „requester“ wird. Die Bearbeitung der vorhandenen HITs

erfolgt dann durch „worker“, für eine verhältnismäßig geringe Bezahlung. HIT-

Marktplätze sind eine Quelle für günstige Arbeitskräfte, allerdings gibt es bei der

59 Vgl. Jeff Howe (2006b), S. 2. 60 Vgl. Estellés-Arolas, González-Ladrón-de-Guevara (2012), S. 191-193,196. 61 http://www.mturk.com 62 http://www.wikipedia.de 63 http://www.gwap.com/gwap/gamesPreview/espgame 64 Vgl. Doan, Ramakrishnan (2011), S. 87–89. 65 Vgl. Zaidan, Callison-Burch (2011), S. 1221-1222,1226-1228. 66 Vgl. Savage (2012), S. 13–15. 67 Vgl zu diesem Absatz Ipeirotis (2010), S. 16–17. 68 Vgl. Jeff Howe (2006a), S. 1.

13

Nutzung der Plattformen neben dem Problem der schwierigen Qualitätssicherung auch

ethische Fragen mit denen man sich beschäftigen sollte.69

Bei GWAP ist es das Ziel, dass schwer automatisierbare Aufgaben gelöst werden,

während das Spiel gespielt wird.70 Häufig wird dabei die menschliche Fähigkeit, Bilder

und Muster zu verarbeiten, genutzt, um beispielsweise das Universum zu erkunden.71

Besonders in der Medizin und Biologie sind GWAP beliebt, da sich Aufgaben, wie die

graphische Neuanordnung von Proteinen72 oder die Zusammensetzung von DNA-

Sequenzen73, sehr gut als Spiel umsetzen lassen.74 Zur Qualitätssicherung von

Crowdsourcing Ergebnissen eigenen sich sogenannte Output-Agreement-Games, bei

denen zwei voneinander unabhängige Parteien auf einen gegebenen Input den gleichen

Output angeben.75

4. Anforderungskatalog

4.1 Anforderungen

Ziel der Arbeit ist die Entwicklung eines Konzepts für ein System zur Verarbeitung

persönlicher Patientendaten, daher ist es nötig, Vorschriften bezüglich der Übertragung

von (personenbezogenen) Daten zu beachten. Es werden dabei nur Bereiche behandelt,

aus denen sich Anforderungen für das Konzept zur Generierung inhaltlich richtiger und

für Laien verständlicher Informationen ergeben. Nicht berücksichtigt werden

beispielsweise Meldepflichten oder die Notwendigkeit der Zustimmung des Patienten.

In diesem Kapitel werden Anforderungen erarbeitet, die Crowdsourcing-Systeme für

medizinische Daten erfüllen müssen. Zur Identifikation von Anforderungen wurden

gesetzliche Vorschriften und Standards betrachtet, sowie die in Kapitel 2 und 3

beschriebenen elektronischen Gesundheitssysteme und Crowdsourcing-Methoden

untersucht.

69 Vgl. Fort, Adda, Cohen (2011), S. 413-414,417-418. 70 Vgl. von Ahn, Dabbish (2008), S. 60. 71 Galaxy Zoo ist ein GWAP, bei dem die Spieler Formen in astronomischen Bildern klassifizieren. http://www.galaxyzoo.org/ 72 http://fold.it/portal 73 http://phylo.cs.mcgill.ca/eng/play.html 74 Vgl. Savage (2012), S. 13–14. 75 Vgl. von Ahn, Dabbish (2008), S. 61–62.

14

4.1.1 Input-Qualitätssicherung

Als Erstes wird die Richtlinie 95/46/EG76 des Europäischen Parlaments zum Schutz

natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien

Datenverkehr betrachtet. In Artikel 6 werden „Grundsätze in Bezug auf die Qualität der

Daten“ abgehandelt. Dort ist unter anderem nachzulesen, dass personenbezogene Daten

„sachlich richtig und, wenn nötig, auf den neuesten Stand gebracht sind; es sind alle

angemessenen Maßnahmen zu treffen, damit im Hinblick auf die Zwecke, für die sie

erhoben oder weiterverarbeitet werden, nichtzutreffende oder unvollständige Daten

gelöscht oder berichtigt werden“. Daraus ergibt sich die Anforderung der Input-

Qualitätssicherung. Genutzte PHRs müssen folglich auf die Richtigkeit der

enthaltenen Angaben überprüft werden, bevor eine Transformation oder Anreicherung

stattfinden darf. Neben den Daten, die von einem Gesundheitsinstitut eingetragen

wurden und mit hoher Wahrscheinlichkeit korrekt sind, kann ein PHR auch vom

Patienten selbst erstellte Einträge beinhalten. Da es Patienten ohne medizinische

Vorbildung gibt, ist die Kontrolle selbst erstellter Daten besonders wichtig.

4.1.2 Desidentifikation

In Artikel 7 und 8 der Richtlinie 95/46/EG wird gefordert, dass die betroffene Person

ohne jeden Zweifel eine Einwilligung für die Verarbeitung ihrer Daten gegeben hat. EU

Richtlinien implizieren zudem, dass Patientendaten nur an qualifiziertes medizinisches

Personal weitergegeben werden dürfen.77 Eine Identifikation und Verifikation der

Personen, die die Daten aufarbeiten, widerspricht jedoch dem Crowdsourcing-Gedanken

des Auslagerns von Aktivitäten in eine breite, unbekannte Masse von Menschen. Nach

dem Entfernen von Merkmalen die zur Identifizierung des Patienten genutzt werden

könnten, handelt es sich nicht mehr um personenbezogene Daten.78 Die

Anonymisierung der Daten ist daher nötig, um Einschränkungen durch die EU

Richtlinie zu vermeiden und wird als Anforderung aufgenommen. Damit Nutzer des

Systems ihre eigenen Daten nach der Transformation einsehen können, müssen die

Daten im Hintergrund zuordnungsbar bleiben. Wenn Daten von autorisierten Personen

zugeordnet werden können, spricht man nicht mehr von Anonymisierung, sondern von

76 Europäisches Parlament, Rat (1995). 77 Vgl. van der Linden u. a. (2009), S. 149. 78 Vgl. Berman (2002), S. 28.

15

Desidentifikation.79 Durch Desidentifikation wird es also möglich, Patientendaten zur

Aufbereitung an die Crowd zu geben und dem Nutzer, durch die Präsentation seiner

persönlichen, aufbereiteten Daten Mehrwert zu bieten. Ob Desidentifikation von

Patientendaten ausreicht, um die Privatsphäre der Patienten zu schützen ist umstritten,

außerdem sind die desidentifizierten Daten nicht einheitlich reguliert.80 Da der Fokus

der Arbeit nicht auf Rechtsprechung liegt, wird im Folgenden davon ausgegangen, dass

Desidentifikation in Verbindung mit der Zustimmung der Nutzer, für die hiesige

Betrachtung ausreicht.

4.1.3 Interoperabilität

Die Fähigkeit eines IT Systems mit einem anderen System Daten auszutauschen, ohne

Zusatzaufwand für den Nutzer zu verursachen, wird als Interoperabilität bezeichnet.81

Bei der Beschreibung der medizinischen Daten in Kapitel 2.2 wurde bereits

angesprochen, dass es verschiedene Formate für Patientendaten gibt. Eine Untersuchung

mehrerer Fallstudien, die sich mit Datenstandards im Gesundheitswesen befasst haben,

hat gezeigt, dass in der Praxis verschiedene Datenstandards genutzt werden.82 In

mehreren Standards, beispielsweise der ISO/TR 18308, in der sich Anforderungen an

EHR-Systeme finden, wird Interoperabilität explizit als Anforderung genannt.83 Um ein

System zu schaffen, dass möglichst viele Patienten nutzen können, müssen gängige

Standards implementiert werden, daher wird Interoperabilität als weitere Anforderung

aufgenommen.

4.1.4 Ergebnis-Qualitätssicherung

Durch die Transformation der Daten sollen diese den Nutzern verständlich gemacht

werden. Im Optimalfall soll ein Nutzer seine Krankengeschichte, Werte und

Testergebnisse genauer versteht. Durch das bessere Verständnis kann ein Nutzer unter

Umständen das Gefühl bekommen, selbst Krankheiten erkennen und behandeln zu

können, was per Definition als Diagnose bezeichnet wird.84 Selbstdiagnosen sind in der

79 Vgl. Berman (2002), S. 29. 80 Vgl. Rothstein (2010), S. 1–2. 81 Vgl. Hufnagel (2009), S. 43. 82 Vgl. Katherine Kim (2005), S. 11,13,15,16. 83 Vgl. Begoyan (2007), S. 3. 84 Vgl. Dudenredaktion (2001), S. 289.

16

Medizin jedoch sehr umstritten und können zu ethischen Problemen führen.85 Ungenaue

Informationen, Fehlinterpretation der Informationen oder eine daraus falsch abgeleitete

Behandlung könnten schlimme Folgen bis hin zum Tod haben.86 Von Systemseite muss

daher alles Mögliche getan werden, um den negativen Aspekten entgegenzuarbeiten.

Nutzer können nicht gehindert werden, Selbstdiagnosen zu stellen oder sich in

Eigeninitiative zu behandeln, aber es muss für eine möglichst hohe Qualität und

Korrektheit der transformierten Daten gesorgt werden. Ergebnis-Qualitätssicherung

wird dementsprechend als Anforderung aufgenommen. Die Sicherstellung der

Ergebnisqualität liegt auch im Interesse des Systembetreibers, da bei fehlerhaften Daten

Kosten aus den Folgen möglicher Klagen und Schadensersatzforderungen entstehen

können87.

4.2 Anforderungsframework

Zusammenfassend lassen sich folgende Kriterien identifizieren, die ein Crowdsourcing

System für medizinische Daten erfüllen muss:

Interoperabilität mit wichtigen Datenformaten.

Qualitätssicherung der Daten, die im System verarbeitet werden.

Qualitätssicherung der Ergebnisse, die sich aus der Verarbeitung ergeben.

Desidentifikation der Daten.

Des Weiteren dienen die in Kapitel 3 besprochenen, relevanten Charakteristiken von

Crowdsourcing Systemen als Orientierung bei der Systemkonzeption:

Wer stellt die Crowd zusammen?

Was muss die Crowd machen?

Was erhält die Crowd als Gegenleistung?

Um welchen Prozesstyp handelt es sich?

Welche Art des Aufrufs wird genutzt?

Welches Medium wird genutzt?

Als grobe Vorlagen dienen zudem die Beispiele der vorgestellten Systemtypen:

Marktplatz für Human Intelligence Tasks.

Games with a purpose.

85 Vgl. Kearns, O'Mathúna, Scott (2010), S. 201–204. 86 Vgl. Kearns, O'Mathúna, Scott (2010), S. 204–205. 87 Vgl. Cios, Moore (2002), S. 8–9.

17

5. Systemkonzeption

Bisher wurden medizinische Daten und Crowdsourcing untersucht und ein

Anforderungsframework für ein Crowdsourcing System zur Transformation und

Anreicherung medizinischer Daten erstellt. In diesem Kapitel wird nun ein Vorschlag

für einen Systementwurf entwickelt.

Abb. 5-1: Prozessablauf des Systems

In Abb. 5-1 sind die einzelnen Prozessschritte des Systems in vier Abschnitte unterteilt,

wobei die Abschnitte aus den in Kapitel 4.1. erarbeiteten Anforderungen abgeleitet sind.

Diese Abschnitte werden im Folgenden detailliert besprochen.

5.1 Import

Um Daten verarbeiten zu können, muss man erst mal dafür sorgen, dass die Daten in

unser System kommen. In diesem Schritt muss besonders auf die Anforderung der

Interoperabilität geachtet werden. Betrachtet man die große Anzahl an Systemen und

Datenformaten, in denen Patientendaten gespeichert sind, ist es dringend nötigt, dass

Import-Funktionen für möglichst viele Datenformate implementiert werden. Des

Weiteren wäre ein application programming interface (API) für die Interaktion mit

vorhandenen Systemen hilfreich. Mittels einer solchen API wäre es möglich,

Patientendaten aus Systemen zu nutzen, die ihre Daten in keines der vom System

unterstützten Formate exportieren können. Zusätzlich könnten externe

Datenmigrationsdienste entwickelt werden, die auf der API aufsetzen und die

Interoperabilität weiter verbessern würden.

Import • Import externer Patientendaten.

Auf-bereitung

• Aufbereitung der Patientendaten, um sie fürs Crowdsourcing verwendbar zu machen.

Trans-formation

• Transformation und Anreicherung der Daten durch Crowdsourcing.

Qualitäts-sicherung

• Qualitätssicherung der Ergebnisse des Crowdsourcing.

18

Abb. 5-2: Importwege für Patientendaten

Die beiden Möglichkeiten Daten in das System zu importieren sind in Abb. 5-2

dargestellt. Wird die API zum Übertragen der Patientendaten genutzt, muss es eine

Möglichkeit geben, die Daten sicher einem authentifizierten Nutzer zuzuordnen, womit

auch dessen Zustimmung gegeben ist. Neben der Verwendung von Zertifikaten und

Verschlüsselungstechniken, für die sichere Übertragung, ist die Nutzung von

Passwörtern und Security-Token für die Identifikation und Authentifizierung sinnvoll.88

Der Anforderung der Input-Qualitätssicherung kann bei Nutzung der API leicht

nachgekommen werden. Geht man davon aus, dass vorhandene Systeme korrekte Daten

enthalten, kann auf eine weitere Prüfung der Daten verzichtet werden. Da sich andere

Systeme ebenfalls an die Richtlinien halten müssen, ist die Annahme der Korrektheit

gerechtfertigt. Problematischer ist es bei manuell importierten Daten. Wenn dort nicht

sichergestellt werden kann, dass die Daten aus einem anderen System übernommen

wurden und unverändert weitergegeben worden sind, muss eine ausführlichere

Qualitätskontrolle erfolgen. Die Daten müssen zur Kontrolle aber bereits im System

sein. Diese Problematik wird im kommenden Abschnitt diskutiert.

5.2 Aufbereitung

Nach dem Import liegen die Daten im System vor. Stammen die Daten aus einem

manuellen Import, muss noch eine Qualitätskontrolle erfolgen. Damit eine

Transformation und Anreicherung der Daten, die qualitativ unbedenklich sind, mittels

Crowdsourcing möglich ist, müssen sie aufbereitet werden. Bei der Aufbereitung geht

es primär darum, dass die Anforderung der Desidentifikation erfüllt wird. Sofern es

sinnvoll möglich ist, kann auch noch eine Zerlegung in Unteraufgaben erfolgen. Die

Aufbereitung der Daten erfolgt praktisch in drei Schritten, in Abb. 5-3 ist die Abfolge

dargestellt.

88 Vgl. Chao, Twu, Hsu (2005), S. 227,229-231.

19

Abb. 5-3: Schema für die Aufbereitung der Patientendaten

Bei der Kontrolle handelt es sich um eine Plausibilitätsprüfung. Da medizinische Daten

nicht immer eindeutig richtig oder falsch sein können, muss geprüft werden, ob die

einzelnen Werte in plausiblen Bereichen liegen und ob die Kombination der Werte mit

ausreichend hoher Wahrscheinlichkeit einem plausiblem Muster entspricht. Für die

Kontrolle von Zahlen und Zahlenbereichen eignet sich eine automatisierte Prüfung

natürlich hervorragend. Bei Daten, die in Textform vorliegen, beispielsweise die

Diagnose eines Knochenbruches, könnte man versuchen, die einzelnen

Elemente/Diagnosen zu kodieren und dann wiederum prüfen wie wahrscheinlich diese

Kombinationen ist. Ein lernendes System würde sich hier anbieten und dazu führen,

dass die Kontrolle mit der Zeit an Genauigkeit gewinnt. Dafür könnten auch die als

korrekt angenommenen Daten die über die API eingespielt wurden genutzt werden.

Eine nachgelagerte, manuelle Prüfung erscheint dennoch, vor allem anfangs, sinnvoll.

Dies könnte ebenfalls mittels Crowdsourcing realisiert werden. Beispielsweise mittels

eines Output-Agreement-Games, bei dem die Daten als plausibel oder fehlerhaft

eingeordnet werden müssen.

Der Vorgang der Desidentifikation ist relativ simpel. Im „Health Insurance Portability

and Accountability Act“ (HIPAA)89 findet sich eine Beschreibung, wie dabei

vorzugehen ist. Alle Einträge in den Daten, die den Rückschluss auf die Person

ermöglichen, müssen entfernt werden, dazu gehören beispielsweise Name, Wohnort,

Telefon-, Sozial- und Krankenversicherungsnummer. Zur Implementierung müssten alle

unterstützten Datenformate untersucht werden und entsprechende Elemente in der

Datenstruktur identifiziert werden. Bei der Desidentifikation werden die restlichen

Daten in einem neuen Datensatz gespeichert, der intern über eine eindeutige Nummer

89 http://www.hhs.gov/ocr/privacy

20

wieder zu den persönlichen Daten zugeordnet werden kann. Zusätzlich sollten Parser

genutzt werden, die Freitext-Elemente nach kritischen Begriffen oder

Zahlenkombinationen durchsuchen.

Eine Zerlegung der Daten ist häufig komplex und hängt von mehreren Faktoren ab,

daher sollte dies auch nur geschehen, wenn es wirklich problemlos machbar ist. Sollten

die Daten beispielsweise bereits beim Import in einem Datenformat vorgelegen haben,

das eine Unterteilung vorgenommen hat, kann diese Unterteilung übernommen werden.

Des Weiteren kann hier auch auf die Muster zurückgegriffen werden, die bei der

Kontrolle des Imports genutzt werden. Sind in den Daten bekannte Diagnosemuster

oder Krankheitsbilder erkennbar, können die dazugehörigen Werte und Texte als

isoliertes Paket kombiniert werden. Bei der Zerlegung besteht jedoch die Gefahr, dass

Informationen verloren gehen, die für die Einordnung und Interpretation der restlichen

Daten benötigt werden.

Nach der Aufbereitung können die Daten, zur Transformation und Anreicherung an die

Crowd gegeben werden.

5.3 Transformation und Anreicherung

Dieser Abschnitt stellt das Herzstück des Systems dar, da durch die Transformation und

Anreicherung Mehrwert für den Nutzer geschaffen wird. Für Übersetzungen und

Wissenssammlungen haben sich Wiki-basierte Plattformen bewährt, dies gilt sowohl für

eines der erfolgreichsten Crowdsourcing-Projekte „Wikipedia“ selbst,90 als auch für

spezifischere Anwendungen, wie die Übersetzung alter, handgeschriebener

Manuskripte91. Diese Systeme haben eine Arbeitsplattform und verschiedene

Nutzerrollen, beispielsweise eine Unterscheidung zwischen Lesern und Redakteuren.

Der vorgestellte Ansatz geht ebenfalls von einem Wiki-artigen System aus, das in

unserem Fall aus den allgemeinen Beschreibungen der Krankheiten ein Template

ableitet, um die spezifischen Patientendaten-Elemente zu generieren. Sollte das

Template zu allgemein sein, gibt es auch die Möglichkeit Kommentare zu erstellen, die

auf einen konkreten Datensatz bezogen sind. Es sei angemerkt, dass wir hier den Begriff

„Krankheit“ benutzen, da wir davon ausgehen, dass hauptsächlich erkrankte Personen

diesen Dienst nutzen würden, es kann sich bei der Diagnose jedoch auch um den

90 Vgl. Doan, Ramakrishnan (2011), S. 86-88,91. 91 Vgl. Causer, Tonra, Wallace (2012), S. 121–123.

21

Ausschluss einer Krankheit handeln. Der Nutzer hat die Möglichkeit, die allgemeinen

Beschreibungen und die spezifischen Kommentare zu bewerten. Dieses Zusammenspiel

von Nutzern, Daten und der Crowd ist in Abb. 5-4 dargestellt.

Abb. 5-4: Transformation und Anreicherung der Daten

Die zuvor aufbereiteten Daten werden auf der Plattform hinterlegt und anfangs als

„unklar“ gekennzeichnet, was bedeutet, dass noch kein Krankheitsbild zugeordnet

wurde. Wenn sich jemand aus der Crowd auf der Plattform anmeldet, bekommt er

unklare Datensätze angezeigt und kann diese einer Krankheit zuordnen. Sollte noch

keine passende Krankheit auf der Plattform existieren, kann diese angelegt werden.

Wenn ein Spezialfall einer Krankheit vorliegt, besteht die Möglichkeit, dass ein

zusätzlicher Kommentar zum Datensatz hinzugefügt wird.

Als Nutzer kann man die Verständlichkeit der Krankheitsbeschreibungen und der

Kommentare bewerten und Rückfragen stellen. Je schlechter die Bewertung, desto

auffälliger wird der entsprechende Text für Überarbeitungen vorgeschlagen. Es kann

überlegt werden, ob die Stimmen gewichtet werden. Beispielsweise sollte die

Bewertung eines Kommentars wichtiger sein, wenn sie von dem Nutzer stammt, dem

der Datensatz zugeordnet ist.

Nachdem die Daten in diesem Abschnitt mit verständlichen Beschreibungen und

Kommentaren ausgestattet wurden, folgt im nächsten Abschnitt als letzter Schritt die

Qualitätssicherung.

5.4 Qualitätssicherung

Das Hauptziel -ein System zur Transformation von medizinischen Daten zu

konzipieren,- wurde im vorigen Abschnitt erreicht. Um der letzten verbleibenden

Anforderung gerecht zu werden, müssen noch Möglichkeiten zur Qualitätssicherung der

Ergebnisse gefunden werden.

22

Es hat sich gezeigt, dass selbst-organisierte Communities qualitativ hochwertige

Informationen produzieren können.92 Dabei spielen drei Faktoren eine Rolle:

Unterscheidung zwischen administrativen und redaktionellen Aufgaben, Diversität

innerhalb der Personen die Beiträge liefern und der Umgang mit Konflikten bei der

Bearbeitung.93 Bei der Umsetzung der Plattform muss auf diese Faktoren geachtet

werden. Dies bedeutet, dass ein entsprechendes Rechtesystem zu implementieren ist

und Personen für die anfallenden administrativen und konfliktlösenden Aufgaben

eingesetzt werden müssen. Außerdem müssen verschiedene Gruppen motiviert werden

mitzuarbeiten, um die nötige Diversität zu erreichen.

Auch zur Ergebnis-Qualitätssicherung können Output-Agreement-Games genutzt

werden. Die Überprüfung der Zuordnungen von Daten zu Krankheiten ist dafür

prädestiniert. Zwei Personen bekommen einen Datensatz angezeigt und müssen eine

Zuordnung vornehmen, ordnen beide es der gleichen Krankheit zu, ist die

Wahrscheinlichkeit einer korrekten Zuordnung höher. Eine Variante ist das Input-

Agreement-Game, dabei würden verschiedene Datensätze, die der gleichen Krankheit

zugeordnet sind, angezeigt und es muss angegeben werden ob die Daten zur gleichen

Krankheit passen.

Abb. 5-5: Maßnahmen zur Qualitätssicherung

Aufgrund der hohen Komplexität medizinischer Daten ist nicht davon auszugehen, dass

alle Beschreibungen und Zuordnungen fehlerfrei und konfliktfrei ablaufen. Es ist daher

wohl nötig, mit einigen Experten zu kooperieren, die zu Rate gezogen werden können,

wenn die restlichen Methoden innerhalb einer gewissen Zeit nicht zum gewünschten

Ergebnis führen. Die vorgestellten Maßnahmen sind in Abb. 5-5 dargestellt.

92 Vgl. Arazy u. a. (2011), S. 71. 93 Vgl. Arazy u. a. (2011), S. 74–76.

23

6. Fazit und Ausblick

Ziel dieser Arbeit ist es, ein Konzept für die Transformation und Anreicherung

medizinischer Daten mittels Crowdsourcing zu entwerfen. In den ersten beiden Kapiteln

werden die Grundlagen medizinischer Daten und des Crowdsourcing besprochen. Dann

werden auf Basis der beiden Grundlagenkapitel und zusätzlicher Betrachtungen von

Normen und Richtlinien Anforderungen formuliert, die während der Konzeption zu

beachten sind. Abschließend wird ein System entworfen, das die gefundenen

Anforderungen erfüllt.

Das vorgestellte System erfüllt alle Anforderungen und es werden häufig mehrere

Faktoren genannt, die für die Erfüllung zu beachten sind. Das System kann an

unterschiedliche Situationen angepasst werden, indem der Implementierungsgrad dieser

Faktoren variiert wird. Es ist beispielsweise vorstellbar, das eine Qualitätssicherung der

Ergebnisse nicht nötig ist, wenn rechtsgültige Wege für einen Haftungsausschluss

gefunden werden.

Es muss kritisch gesehen werden, dass die Konzeption sich hauptsächlich an der

Erfüllung von Richtlinien und Standards orientiert, da dies keinesfalls zu einem

erfolgreichen System führen muss. Dafür sollten weitere Überlegungen und

Untersuchungen der Erfolgsfaktoren durchgeführt werden. Diesbezüglich seien

beispielsweise die Gestaltungsmöglichkeiten des offenen Aufrufs genannt, die in

Kapitel 3.1.2 kurz angesprochen wurden. Außerdem scheint das vorgestellte System für

die einfach klingende Aufgabe der Transformation und Anreicherung von Daten sehr

umfangreich zu sein. Es ist die Frage, ob sich ein solches System wirtschaftlich

betreiben ließe, ohne es in eine bestehende Umgebung zu integrieren, die Teile der

Aufgaben übernimmt oder querfinanziert. Ebenso ist die technische Realisierung,

beispielsweise der Desidentifikation oder der Datenzerlegung keinesfalls trivial und

könnte zum Scheitern des Systems führen.

Abschließen ist zu sagen, dass ein Systemkonzept für die Transformation und

Anreicherung medizinischer Daten mittels Crowdsourcing erstellt und damit das

Hauptziel der Arbeit erreicht ist. Bis zur Implementierung eines erfolgreichen und

wirtschaftlichen Systems sind jedoch noch viele Detailfragen zu klären.

24

Literaturverzeichnis

American Medical Association (2011a) American Medical Association: Electronic Medical Records and Electronic Health Records. http://www.ama-assn.org/ama/pub/physician-resources/health-information-technology/health-it-basics/emrs-ehrs.page, Abruf am 22.5.2012

American Medical Association (2011b) American Medical Association: Health IT Glossary. http://www.ama-assn.org/ama/pub/physician-resources/health-information-technology/resources/glossary.page?, Abruf am 22.5.2012

Anastasiou, Gupta (2011) Dimitra Anastasiou, Rajat Gupta: Comparison of crowdsourcing translation with Machine Translation. In: Journal of Information Science. Nr. 6, Jg. 37, 2011, S. 637-659

Arazy u. a. (2011) Ofer Arazy, Oded Nov, Raymond Patterson, Lisa Yeo: Information Quality in Wikipedia: The Effects of Group Composition and Task Conflict. In: Journal of Management Information Systems. Nr. 4, Jg. 27, 2011, S. 71-98

Barry D. Weiss (2009) M. Barry D. Weiss: Health literacy and patient safety: Help patients understand. Manual for clinicians. Chicago 2009

Begoyan (2007) A. Begoyan: AN OVERVIEW OF INTEROPERABILITY STANDARDS FOR ELECTRONIC HEALTH RECORDS. In: SDPS (Hrsg.): Integrated Design and Process Technology, IDPT-2007, 2.-8.6.2007, Antalya. USA. 2007, S. o. A.

Berman (2002) Jules J. Berman: Confidentiality issues for medical data miners. In: Artificial Intelligence in Medicine. 1/2, Jg. 26, 2002, S. 25

Caligtan, Dykes (2011) Christine A. Caligtan, Patricia C. Dykes: Electronic Health Records and Personal Health Records. In: Seminars in Oncology Nursing. Nr. 3, Jg. 27, 2011, S. 218-228

Causer, Tonra, Wallace (2012) Tim Causer, Justin Tonra, Valerie Wallace: Transcription maximized; expense minimized? Crowdsourcing and editing The Collected Works of Jeremy Bentham*. In: Literary & Linguistic Computing. Nr. 2, Jg. 27, 2012, S. 119-137

Chao, Twu, Hsu (2005) Hui-Mei Chao, Shih-Hsiung Twu, Chin-Ming Hsu: A patient-identity security mechanism for electronic medical records during transit and at rest. In: Medical Informatics And The Internet In Medicine. Nr. 3, Jg. 30, 2005, S. 227-240

Cios, Moore (2002) Krzysztof J. Cios, G. W. Moore: Uniqueness of medical data mining. In: Artificial Intelligence in Medicine. 1-2, Jg. 26, 2002, S. 1-24

Dick, Steen, Detmer (1997) Richard Dick, Elaine Steen, Don Detmer: The Computer-Based Patient Record:An Essential Technology for Health Care, Revised Edition. Washington, D.C. 1997

Doan, Ramakrishnan (2011) Anhai Doan, Raghu H. A. Ramakrishnan: Crowdsourcing Systems on the World-Wide Web. In: Communications of the ACM. Nr. 4, Jg. 54, 2011, S. 86-96

25

Dudenredaktion (2001) Dudenredaktion: Duden. 22., völlig neu bearbeitete und erweiterte Auflage. Mannheim 2001

Estellés-Arolas, González-Ladrón-de-Guevara (2012) Enrique Estellés-Arolas, Fernando González-Ladrón-de-Guevara: Towards an integrated crowdsourcing definition. In: Journal of Information Science. Nr. 2, Jg. 38, 2012, S. 189

Europäisches Parlament, Rat (1995) Europäisches Parlament, Rat: Richtlinie 95/46/EG des Europäischen Parlaments und des Rates vom 24. Oktober 1995 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr. Richtlinie 95/46/EG. 1995

Fort, Adda, Cohen (2011) Karën Fort, Gilles Adda, K. B. Cohen: Amazon Mechanical Turk: Gold Mine or Coal Mine? In: Computational Linguistics. Nr. 2, Jg. 37, 2011, S. 413-420

Häyrinen, Saranto, Nykänen (2008) Kristiina Häyrinen, Kaija Saranto, Pirkko Nykänen: Definition, structure, content, use and impacts of electronic health records: A review of the research literature. In: International Journal of Medical Informatics. Nr. 5, Jg. 77, 2008, S. 291-304

Health Information Management and Systems (2004) Health Information Management and Systems: National Health Information Infrastructure Survey. http://www.himss.org/content/files/2004HealthInfoInfrastructureSurvey.pdf, Abruf am 25.6.2012

Heer, Bostock (2010) Jeffrey Heer, Michael Bostock: Crowdsourcing graphical perception: using mechanical turk to assess visualization design. In: ACM (Hrsg.): Proceedings of the 28th international conference on Human factors in computing systems, 10.-15.4.2010, Atlanta. New York, NY, USA 2010, S. 203‐212

Hufnagel (2009) Stephen P. Hufnagel: Interoperability. In: Military Medicine. Nr. 5, Jg. 174, 2009, S. 43-50

Ipeirotis (2010) Panagiotis G. Ipeirotis: Analyzing the Amazon Mechanical Turk marketplace. In: XRDS. Nr. 2, Jg. 17, 2010, S. 16‐21

ISO (2009) ISO (Hrsg.): Business requirements for health summary records -- Part 1: Requirements. ISO/TR: 2009. Geneva 2009

Jeff Howe (2006a) Jeff Howe: Taking Measure of Mechanical Turk. http://www.crowdsourcing.com/cs/2006/11/taking_measure_.html, Abruf am 19.6.2012

Jeff Howe (2006b) Jeff Howe: The Rise of Crowdsourcing. http://www.wired.com/wired/archive/14.06/crowds.html, Abruf am 23.5.2012

Kaletsch, Sunyaev (2011) Alexander Kaletsch, Ali Sunyaev: Privacy Engineering: Personal Health Records in Cloud Computing Environments. In: ICIS (Hrsg.): Proceedings of the International Conference on Information Systems, 4.-7.12.2011, Shanghai. Shanghai 2011, S. Paper 2

Kassenärztliche Bundesvereinigung (2012) Kassenärztliche Bundesvereinigung: Schnittstellen. http://www.kbv.de/ita/4274.html, Abruf am 28.06.2012

26

Kassenärztliche Bundesvereinigung (2012) Kassenärztliche Bundesvereinigung: Schnittstellen. http://www.kbv.de/ita/4201.html, Abruf am 26.5.2012

Katherine Kim (2005) Katherine Kim: Clinical Data Standards in Health Care: Five Case Studies. Oakland 2005

Kearns, O'Mathúna, Scott (2010) Alan Kearns, Dónal P. O'Mathúna, P. A. Scott: DIAGNOSTIC SELF-TESTING: AUTONOMOUS CHOICES AND RELATIONAL RESPONSIBILITIES. In: Bioethics. Nr. 4, Jg. 24, 2010, S. 199-207

La Vecchia, Cisternino (2010) Gioacchino La Vecchia, Antonio Cisternino: Collaborative workforce, business process crowdsourcing as an alternative of BPO. In: F. Daniel, F.M Facca (Hrsg.): Proceedings of the 10th international conference on Current trends in web engineering, 5.-6.7.2010, Vienna. Berlin, Heidelberg 2010, S. 425‐430

Lin u. a. (2012) Chi-Hung Lin, I-Chun Lin, Jin-Sheng Roan, Jehn-Shan Yeh: Critical Factors Influencing Hospitals’ Adoption of HL7 Version 2 Standards: An Empirical Investigation. In: Journal of Medical Systems. Nr. 3, Jg. 36, 2012, S. 1183-1192

Matteo Negri, Yashar Mehdad (2010) Matteo Negri, Yashar Mehdad: Creating a bi-lingual entailment corpus through translations with Mechanical Turk: \$100 for a 10-day rush. In: ACL (Hrsg.): Proceedings of the NAACL HLT 2010 Workshop on Creating Speech and Language Data with Amazon's Mechanical Turk. Los Angeles, California 2010, S. 212-216

Modern Healthcare (2011) Modern Healthcare: Himss analytics. By the Numbers. Top vendors of acute-care EHR systems. http://www.modernhealthcare.com/article/20110307/DATA/110309996, Abruf am 25.5.2012

Ortega Egea, González, Menéndez (2010) José M. Ortega Egea, María V. R. González, Manuel R. Menéndez: eHealth usage patterns of European general practitioners: A five-year (2002–2007) comparative study. In: International Journal of Medical Informatics. Nr. 8, Jg. 79, 2010, S. 539-553

Pedersen, Hasselbring (2004) Susanne Pedersen, Wilhelm Hasselbring: Interoperabilität für Informationssysteme im Gesundheitswesen auf Basis medizinischer Standards. (German). In: Informatik - Forschung und Entwicklung. Nr. 3, Jg. 18, 2004, S. 174

Prokosch (2010) Hans-Ulrich Prokosch: Glossar Medizinische Informatik. http://www.imi.med.uni-erlangen.de/fileadmin/Forschung/Publikationen_pdf/medinfgrund_ss2010_glossar.pdf, Abruf am 23.5.2012

Quinn, Bederson (2011) Alexander Quinn, Benjamin Bederson: Human computation: a survey and taxonomy of a growing field. In: ACM (Hrsg.): Proceedings of the 2011 annual conference on Human factors in computing systems, 7.-12.5.2011, Vancouver. New York, NY, USA 2011, S. 1403-1412

Reinhold (2006) Haux Reinhold: Health information systems – past, present, future. In: International Journal of Medical Informatics. Electronic Health Record, Healthcare Registers and Telemedicine" and "European Potential for Building Information Society in Healthcare, Jg. 75, 2006, S. 268-281

Rothstein (2010) Mark A. Rothstein: IS DEIDENTIFICATION SUFFICIENT TO PROTECT HEALTH

27

PRIVACY IN RESEARCH? In: Current. Nr. 527, Jg. 9, 2010, S. 17-24

Rusu u. a. (2010) Mircea Rusu, Gavril Saplacan, Gheorghe Sebestyen, Nicolae Todor, Lorand Krucz, Cristian Lelutiu: eHealth: Towards a Healthcare Service-Oriented Boundary-Less Infrastructure. In: Applied Medical Informatics. Nr. 3, Jg. 27, 2010, S. 1-14

Savage (2012) Neil Savage: Gaining wisdom from crowds. In: Communications of the ACM. Nr. 3, Jg. 55, 2012, S. 13-15

Schenk, Guittard (2011) Eric Schenk, Claude Guittard: Towards a characterization of crowdsourcing practices. In: Journal of Innovation Economics. Nr. 1, Jg. 7, 2011, S. 1‐20

Stein (1997) Lincoln D. Stein: The electronic medical record: promises and threats. In: World Wide Web J. Nr. 3, Jg. 2, 1997, S. 217‐229

Townend (2010) David Townend: Privacy, health insurance, and medical research: tensions raised by European data protection law. In: New Genetics & Society. Nr. 4, Jg. 29, 2010, S. 477-493

van der Linden u. a. (2009) Helma van der Linden, Dipak Kalra, Arie Hasman, Jan Talmon: Inter-organizational future proof EHR systems: A review of the security and privacy related issues. In: International Journal of Medical Informatics. Nr. 3, Jg. 78, 2009, S. 141-160

von Ahn, Dabbish (2008) Luis von Ahn, Laura Dabbish: Designing Games With A Purpose. In: Communications of the ACM. Nr. 8, Jg. 51, 2008, S. 58-67

Zaidan, Callison-Burch (2011) Omar Zaidan, Chris Callison-Burch: Crowdsourcing translation: professional quality from non-professionals. In: ACL (Hrsg.): Proceedings of the 49th Annual Meeting of the Association for Computational Linguistics: Human Language Technologies - Volume 1. Portland, Oregon 2011, S. 1220-1229

28

Anhang