Generisches Datenschutz- und IT-Sicherheitskonzept für die Forschung mit Daten aus der ambulanten medizinischen Versorgung - ToolPool ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Generisches Datenschutz- und IT-Sicherheitskonzept für die Forschung mit Daten aus der ambulanten medizinischen Versorgung Version 2.2 vom 01.04.2021 Dieses generische Datenschutzkonzept ist im von der DFG geförderten Projekt „Routine Anonymized Data for Advanced Health Services Research“ (RADAR) unter Beteiligung aller Partner entstanden. Es stellt eine Generalisierung eines konkreten Konzepts dar, welches auf Basis einer Abstimmung mit der Ethikkommission der Universitätsmedizin Göttingen, dem Datenschutzbeauftragten des Universitätsklinikums Göttingen sowie der AG Datenschutz der TMF umgesetzt wurde. Die Erstellung wurde durch die Geschäftsstelle des TMF e.V. koordiniert. Die Autorenliste bezieht sich sowohl auf
das zugrundeliegende konkrete Konzept, ohne das dieses generische Konzept nicht hätte entstehen
können, als auch auf die im Rahmen der Generalisierung durchgeführten Arbeiten.
Autoren: Sophie Rybczak5, Valérie Kempter5, Johannes Pung2, Arne Blumentritt3, Thomas Bahls3,
Johannes Hauswaldt1, Stephanie Heinemann1, Falk Schlegelmilch1, Eva Hummers1, Roland Groh4,
Philipp Wieder4, Johannes Drepper5
1
Universitätsmedizin Göttingen, Institut für Allgemeinmedizin
2
Universitätsmedizin Göttingen, Institut für Medizinische Informatik
3
Universitätsmedizin Greifswald
4
Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG)
5
TMF – Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.
13.02.2020 /
Inhalt
1 Einleitung .........................................................................................................................................5
2 Zweckbestimmung ...........................................................................................................................7
2.1 Anwendungsbeispiele ..............................................................................................................7
2.1.1 Nutzung der im Projekt etablierten Routinedatenbank für weitere
exemplarische Forschungsfragen/-anwendungen der
Versorgungsforschung ................................................................................................7
3 Verantwortlichkeiten .......................................................................................................................8
3.1 Verantwortliche Stelle i. S. d. Datenschutzrechts: koordinierende Stelle ...............................8
3.2 Datenzentrum ..........................................................................................................................8
3.3 Unabhängige Treuhandstelle (THS) .........................................................................................8
4 Von den Datenverarbeitungen betroffene Personen......................................................................9
4.1 Patienten ..................................................................................................................................9
4.2 Niedergelassene Allgemeinärzte .............................................................................................9
5 Rechtsgrundlagen ......................................................................................................................... 11
5.1 Verarbeitung von Primärdaten des Patienten ...................................................................... 11
5.2 Verarbeitung von Primärdaten der Arztpraxis ...................................................................... 11
5.3 Verarbeitung von Sekundärdaten (Forschungsdaten) .......................................................... 11
5.4 Einwilligungserklärung .......................................................................................................... 12
5.4.1 Allgemeine Bestandteile einer Einwilligungserklärung ............................................ 12
5.4.2 Breite Zweckbeschreibung ....................................................................................... 13
5.4.3 Breite Zweckbeschreibung nach EU-DSGVO ............................................................ 13
5.5 Entbindung von der ärztlichen Schweigepflicht ................................................................... 14
5.6 Zuständigkeit der Ethik-Kommission .................................................................................... 15
6 Daten und Datenkategorien ......................................................................................................... 16
6.1 Primärdaten der Patienten ................................................................................................... 16
6.1.1 Identitätsdaten (IDAT).............................................................................................. 16
6.1.2 Medizinische Daten (MDAT) .................................................................................... 16
6.2 Primärdaten der Arztpraxis ................................................................................................... 18
6.2.1 Betriebsstättennummer ........................................................................................... 18
6.3 Pseudonyme Sekundärdaten für die Forschung ................................................................... 18
13.02.2020 /6.3.1 Pseudonymisierung der IDATs der Patienten .......................................................... 18
6.3.2 Pseudonymisierung der Betriebsstättennummern der Hausarztpraxen ................. 18
7 Beschreibung der datenbezogenen Prozesse ............................................................................... 20
7.1 Grundlegende datenbezogene Prozesse .............................................................................. 20
7.2 Austausch von Pseudonymen zwischen den Verantwortlichen ........................................... 23
7.3 Datenbezogene Prozesse für die Umsetzung in der Arztpraxis ............................................ 23
7.4 Datenbezogene Prozesse bei Widerrufen ............................................................................ 24
7.4.1 Widerrufe des Patienten .......................................................................................... 24
7.4.2 Vertragskündigung und Widerruf des Arztes ........................................................... 25
7.5 Datenbezogene Prozesse bei Löschungen ............................................................................ 26
7.5.1 Löschung ein Jahr nach Ende des Projekts ............................................................... 26
7.5.2 Löschung bei Aufforderung des Arztes oder des Patienten..................................... 26
7.6 Datenbezogene Prozesse bei Re-Kontaktierung von Patienten und Nacherhebung
von Daten .............................................................................................................................. 26
7.7 Qualitätssicherung betreffend den BDT-Export ................................................................... 27
8 Schutzbedarfsanalyse ................................................................................................................... 29
9 Technische und organisatorische Maßnahmen............................................................................ 30
9.1 Maßnahmen in der Arztpraxis .............................................................................................. 30
9.2 Absicherung der Kommunikationsprozesse ......................................................................... 30
9.2.1 Datenübertragung an die THS .................................................................................. 30
9.2.2 Datenübertragung an das Datenzentrum ................................................................ 30
9.3 Maßnahmen bei der koordinierenden Stelle........................................................................ 31
9.4 Maßnahmen der THS ............................................................................................................ 31
9.5 Maßnahmen im Datenzentrum ............................................................................................ 31
10 Speicherfristen und Löschung ...................................................................................................... 33
11 Anlagen ......................................................................................................................................... 34
13.02.2020 /1 Einleitung Die Gesundheitsforschung und -versorgung in Deutschland profitiert nachhaltig davon, wenn die ständig auflaufenden Daten der ambulanten Krankenversorgung (sog. „Routinedaten“ im Gesundheitswesen) für die wissenschaftliche Forschung (insbesondere Versorgungsforschung) zur Verfügung stehen. International werden Routinedaten aus der Primärversorgung seit langem erfolgreich genutzt. In Deutschland fehlt der Zugriff auf diese Daten jedoch weitgehend bzw. ist nur unter größtem Aufwand möglich. Dass die technischen sowie organisatorischen Erfordernisse bei der Gewinnung und sekundären Aufbereitung von hausärztlichen Routinedaten beherrschbar sind, konnte mittlerweile vielfach gezeigt werden. Für eine zukunftsfeste, fortlaufende sekundäre Routinedatennutzung bedarf es jedoch Standards bei ihrer Erhebung und Auswertung, die vor allem den unverzichtbaren Datenschutz auf höchstem Niveau sowie Datensicherheit gewährleisten. Im vorliegenden Datenschutzkonzept wird ausgehend vom RADAR Projekt (Routine Anonymized Data for Advanced Health Services Research)1 dargestellt, wie Behandlungsdaten von Patienten aus der ambulanten Versorgung bei niedergelassenen Hausärzten datenschutzgerecht erhoben und in pseudonymer Form in einer Forschungsdatenbank gespeichert werden. Diese Daten werden bei einer koordinierenden Stelle für verschiedene Fragen der Versorgungsforschung (vgl. Kap. 2) ausgewertet. Für die Zuordnung der jeweiligen Patienten zur versorgenden Arztpraxis wird die Betriebsstättennummer (BSNR) der Arztpraxis erhoben und verarbeitet (vgl. Kap. 6.2.1). 1 Das RADAR Projekt ist integraler Teil eines seit mehr als 15 Jahre am Institut für Allgemeinmedizin der UMG fortlaufend verfolgten e-Health-Forschungsinteresses, das die sekundäre Nutzung von ambulanten Routinedaten aus hausärztlichen Praxen für Zwecke der allgemeinmedizinischen und Gesundheitssystemforschung sowie der Versorgungsforschung untersucht (http://www.allgemeinmedizin.med.uni-goettingen.de/de/content/forschung/510_591.html). Die Arbeit wurde durch die Deutsche Forschungsgemeinschaft (DFG) unter folgenden Förderkennzeichen gefördert: HU 1587/2-1, HO 1937/7-1, RI 1000/7-1, YA 191/8-1, KR-1093/10-1). Man kann das Projekt daher auch als „Routinedatenprojekt“ beschreiben. Ziel des RADAR Projekts ist es zu zeigen, dass es nicht nur möglich ist, projektbezogen punktuell Routinedaten aus der ambulanten medizinischen Versorgung zu gewinnen und sekundär für Forschungszwecke zu nutzen. Das RADAR Projekt zielt darauf ab, prototypisch die technischen, IT- prozeduralen sowie datenschutzrechtlichen Voraussetzungen für die wiederholte bzw. kontinuierliche Datengewinnung sowie deren längerfristige Speicherung und Nutzung zu entwickeln. Dazu müssen zunächst die gesetzlich definierten Datenschutzerfordernisse erfüllt und damit das „informationelle Selbstbestimmungsrecht“ aller beteiligten Personen (Patienten, Professionelle, Dritte) gewahrt werden. Darüber hinaus sollen prototypische Abläufe und IT-Werkzeuge (Software, Datenbank u. Ä., De- Identifizierungs- und Zugangsroutinen) entwickelt und pilotiert werden. 13.02.2020 /
Die datenschutzrechtlichen Erfordernisse, die gegenwärtig bestehen und wesentlich auf die EU- Datenschutzgrundverordnung2 (im Folgenden: EU-DSGVO) und die Neufassung des BDSG3 zurückgehen, sind von Forschern bei der Nutzung ambulanter Routinedaten zwingend zu beachten. Das RADAR Projekt hat diese umfassend aufgearbeitet und im hier vorgelegten generischen Datenschutzkonzept für die Sekundärnutzung von Daten aus der ambulanten medizinischen Versorgung einen beispielhaften Lösungsweg skizziert, der diese Anforderungen umfassend berücksichtigt.4 Das vorliegende Datenschutzkonzept kann nicht eine Datenschutz-Folgenabschätzung nach Art. 35 EU- DSGVO ersetzen. Diese kann bei Notwendigkeit der Durchführung in künftigen Projekten allerdings auch als Teil eines Datenschutzkonzepts dokumentiert werden, was sich aufgrund vieler gleicher Inhalte empfiehlt. 2 VERORDNUNG (EU) 2016/679 DES EUROPÄISCHEN PARLAMENTS UND DES RATES vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung), http://eur-lex.europa.eu/legal- content/DE/TXT/PDF/?uri=CELEX:32016R0679&from=DE, letzter Zugriff am 02.08.2017. 3 Datenschutz-Anpassungs- und Umsetzungsgesetz-EU wurde am 30.06.2017 verkündet. Das BDSG-neu trat am 25.05.2017 gemeinsam mit der Datenschutzgrundverordnung in Kraft: https://www.bgbl.de/xaver/bgbl/start.xav?startbk=Bundesanzeiger_BGBl&start=//*[@attr_id=%27bgbl117s20 97.pdf%27]#__bgbl__%2F%2F*%5B%40attr_id%3D%27bgbl117s2097.pdf%27%5D__1501661937310, letzter Zugriff am 02.08.2017. 4 In diesem Datenschutzkonzept wird die Rechtslage nach dem bisherigen Datenschutzrecht (Stand: März 2020) geprüft. 13.02.2020 /
2 Zweckbestimmung
Die in der alltäglichen hausärztlichen Versorgung primär zusammengeführten oder neu anfallenden
Behandlungsdaten (sog. Routinedaten) sind eine einzigartige Informationsquelle für die
Versorgungsforschung sowie gesundheitspolitische Entscheidungsfindung. Menschen, die
Gesundheitsprobleme haben, suchen in der Regel als erstes ihren Hausarzt/in auf und besuchen den
gleichen Hausarzt/in über einen längeren Zeitraum. Die Längsschnittdaten aus der
Praxisinformationssoftware eines Hausarztes/ einer Hausärztin ist daher eine reichhaltige
Informationsquelle zur Beantwortung von epidemiologischen und klinischen Fragestellungen. Leider
stehen derzeit diese Routinedaten für Forschungszwecke in Deutschland nicht zur Verfügung, der
Zugang wird durch die Datenschutzgesetze eng limitiert und durch technische und prozedurale
Probleme erschwert.
Vorgehen und Datenauswahl sind im Projekt daher nicht durch eine konkrete Forschungsfrage
bestimmt oder durch ein singuläres Forschungsinteresse begrenzt. Vielmehr sollen breite
Untersuchungsmöglichkeiten eröffnet werden, auch von Aspekten, die bei der Auswahl der
Datenfelder noch nicht zu erkennen waren.
2.1 Anwendungsbeispiele
Nachfolgend wird beschrieben, welche Zwecke mit den vorgenannten Daten erreicht werden können:
2.1.1 Nutzung der im Projekt etablierten Routinedatenbank für weitere exemplarische
Forschungsfragen/-anwendungen der Versorgungsforschung
Mit den Daten kann man z. B.
• Häufigkeiten von Diagnosen (z.B. Diabetes mellitus Typ 2, rheumatischen Erkrankungen, Herz-
Kreislauf-Erkrankungen, usw.) und/oder Leistungen (z.B. Blutuntersuchungen, Grippeimpfung,
Hautkrebsscreening) und/oder Outcomes (z.B. Arbeitsunfähigkeitsbescheinigung,
Krankenhauseinweisung, Lungenfunktion, usw.) in der hausärztlichen Versorgung erfassen und
beschreiben
• Zusammenhänge zwischen (praxis- und versorgungseinrichtungsübergreifenden)5 Mustern der
Nutzung von Versorgung und patientenbezogenen Ergebnissen (Lebensqualität, aber auch
Mortalität und Morbidität) analysieren,
• Routinedaten patientenbezogen mit Forschungsdaten aus anderen Quellen (Fragebögen, eCRFs
klinischer Studien, Biobankparametern) verknüpfen und analysieren,
• Patienten zu (re-) identifizieren und gezielt ansprechen, die gemäß bestimmter Suchkriterien
Kandidaten für klinische Studien sind.
5
Daher wird mit entsprechender Einwilligung des Arztes auch die Betriebsstättennummer pseudonymisiert, um
die Behandlungsdaten der Patienten dieser pseudonymisierten Nummer zuzuordnnen.
13.02.2020 /3 Verantwortlichkeiten
Die Umsetzung des Projekts erfordert unterschiedliche Prozesse, die unter die Regelungen des
Datenschutzrechts fallen. Daher sind die datenschutzrechtlichen Verantwortlichkeiten im Umgang mit
den Daten nachfolgend zu klären.
3.1 Verantwortliche Stelle i. S. d. Datenschutzrechts:
koordinierende Stelle
Hier ist die hauptverantwortliche Stelle für die Datenverarbeitung in dem Projekt unter den in Kap. 1
und 2 beschriebenen Voraussetzungen zu nennen. Diese Stelle wird im vorliegenden generischen
Konzept „koordinierende Stelle“ genannt.
3.2 Datenzentrum
Für die Datenhaltung kann ein Dienstleister eingesetzt werden. Dieser ist hier zu nennen. Ein solcher
Dienstleister wird im vorliegenden generischen Konzept „Datenzentrum“ genannt. Dieser Dienstleister
kann über eine Auftragsverarbeitung nach Art. 28 EU-DSGVO durch die koordinierende Stelle
eingebunden werden, was die eigene Verantwortlichkeit des Dienstleisters entsprechend begrenzt,
wenn auch nicht vollständig eliminiert. Durch eine solche Einbindung als Dienstleister im Rahmen einer
Auftragsverarbeitung erhöht sich aber die Flexibilität bei späteren Anpassungen der
Projektkonstellation.
3.3 Unabhängige Treuhandstelle (THS)
Eine unabhängige Treuhandstelle übernimmt auf Grundlage einer entsprechenden vertraglichen
Vereinbarung6 mit der koordinierenden Stelle die Speicherung und Verwaltung von identifizierenden
Daten der Patienten im Zusammenhang mit den ebenfalls von ihr generierten Pseudonymen. Die
Treuhandstelle ist für die bei ihr verarbeiteten und gespeicherten Daten die verantwortliche Stelle und
insofern an dieser Stelle auch zu nennen.
Sie ist von allen anderen Organisationen rechtlich und organisatorisch unabhängig und keinen
Weisungen unterlegen. Insofern wird mit der THS auch keine Auftragsverarbeitung vereinbart.
6
Im Vertrag ist die Übertragung der Funktion einer THS zwischen koordinierender Stelle und THS geregelt. Er
stellt keine Anlage zu diesem Datenschutzkonzept dar. Eine Zusammenarbeit mehrerer verantwortlicher
Stellen ist nach Art. 26 ff. EU-DSGVO zu bewerten.
13.02.2020 /4 Von den Datenverarbeitungen betroffene Personen
Im Projekt sollen Behandlungsdaten der Patienten von niedergelassenen Allgemeinärzten der
vertragsärztlichen Versorgung (vgl. § 73 Abs. 1 a Nr. 1 SGB V) für Forschungs- und
Qualitätssicherungsfragen genutzt werden. Insbesondere letzteres erfordert auch eine Betrachtung
auf Praxisebene. Um Patienten einer Praxis zuordnen und Praxen ggf. re-identifizieren zu können,
sollen die Betriebsstättennummern der Arztpraxen verwendet werden. Von der Datenverarbeitung in
einem solchen Projekt betroffene Personen sind somit:
4.1 Patienten
Für die Nutzung der primären Behandlungsdaten und der pseudonymisierten Forschungsdaten ist eine
Einwilligung der Patienten in die Datenerhebung und – Verarbeitung durch die vorgenannten Stellen
erforderlich7. Patient ist jede natürliche Person, die sich in den hausärztlichen Praxen medizinisch
behandeln lässt.
Vor der Unterzeichnung der Einwilligung wird der Patient über das Projekt informiert. Hierzu erhält er
eine Patienteninformation zum Projekt und zur Nachnutzungszeit.
Nach Unterzeichnung der Einwilligungserklärung wird eine Kopie der Original-Erklärung dem Patienten
ausgehändigt. Das Original wird in der Arztpraxis aufbewahrt. An die Treuhandstelle wird die
Information über die Einwilligung auf elektronischem Weg geschickt, dort gespeichert und für weitere
Nutzungen ausgewertet.
Bei Nachfrage durch berechtigte Stellen kann der Datenschutzbeauftragte der koordinierenden Stelle
in Kooperation mit der Treuhandstelle und der Arztpraxis die erteilte Einwilligung nachweisen.
Wegen der strafbewehrten Vorschrift des Geheimnisverrats (§ 203 StGB), ist zudem bei der
Weitergabe von personenbezogenen Behandlungsdaten eine Entbindung von der ärztlichen
Schweigepflicht einzuholen, die ebenfalls vom Patienten zu unterschreiben ist. Wenn die zuvor
genannte Einwilligungserklärung sich ausdrücklich auf die Daten aus dem geschützten Verhältnis von
Arzt und Patient bezieht, kann sie auch als konkludente Schweigepflichtentbindung gewertet werden.
Das Original einer separaten Schweigepflichtentbindungserklärung verbleibt im Regelfall in der
Arztpraxis.
4.2 Niedergelassene Allgemeinärzte
Die teilnehmenden Ärzte schließen jeweils einen Teilnahmevertrag mit der koordinierenden Stelle für
die Laufzeit des Projekts ab.8 Die Verarbeitung der Betriebsstättennummer der Arztpraxis ist für die
Teilnahme am Projekt wesentlich, daher erklärt der Arzt mit dem Vertragsabschluss auch zugleich
seine Einwilligung in die Verarbeitung seiner Betriebsstättennummer.
Im Vertrag werden u. a. folgende Punkte geregelt:
7
Vgl. Beschreibungen in Kap. 5.1. und 5.2.
8
Der Teilnahmevertrag und die Einwilligungserklärung des Arztes liegen diesem Konzept nicht als Anlage bei.
13.02.2020 /• Indem der Arzt am Projekt teilnimmt, stimmt er dem Datenexport der Behandlungsdaten (IDATs
und MDATs) seiner Patienten soweit diese eingewilligt haben, in pseudonymisierter Form zu.
• Eine Gegenleistung für den Arzt wird nicht vereinbart.
• Der Arzt erhält keinen Zugang zur Forschungsdatenbank.
• Der Arzt verpflichtet sich zur Aufklärung und Information gegenüber dem Patienten.
• Der Arzt verpflichtet sich dazu, die eingegangen Widerrufe der Patienten an die koordinierende
Stelle weiter zu geben. Nachrangig informiert die koordinierende Stelle die THS.
• Der Arzt kann den Vertrag mit Wirkung für die Zukunft kündigen. Die Kündigung führt auch zu
einem Widerruf seiner datenschutzrechtlichen Einwilligung. Die Rechtsfolgen sind in Kap. 7.4.2
beschrieben.
Die Ärzte erhalten von der koordinierenden Stelle eine ausführliche Information zum Projekt und zur
Datennutzung in der Nachnutzungszeit.
13.02.2020 /5 Rechtsgrundlagen9 Im Projekt werden verschiedene Datensätze verarbeitet (vgl. Kap. 6), die eine unterschiedliche rechtliche Bewertung nach sich ziehen. Dabei ist zunächst zwischen Primär- und Sekundärdaten zu unterscheiden. 5.1 Verarbeitung von Primärdaten des Patienten Im Projekt werden zunächst Primärdaten des Patienten verarbeitet. Wie in Kap. 1 und 2 erläutert, werden für das Projekt personenbezogene Behandlungsdaten des Patienten genutzt. Diese enthalten in einem ersten Schritt sowohl identifizierende als auch medizinische Merkmale (vgl. Kap. 6.1). Seit dem 25.05.2018 ist die EU-DSGVO in Kraft. Für die Nutzung von Gesundheitsdaten für die wissenschaftliche Forschung gilt die EU-DSGVO (vgl. u. a. Art. 4, Art. 5, Abs. 15, Art. 9, Art. 6, Art. 89 EU-DSGVO, Erwägungsgrund 33) und ergänzend das BDSG. Das seit dem 25. Mai 2018 geltende Bundesdatenschutzgesetz (BDSG) ergänzt die Datenschutz-Grundverordnung in den Bereichen, in denen den Mitgliedstaaten der EU Gestaltungsspielräume verbleiben (Öffnungsklauseln der DSGVO). Ergänzend können auch Landesgesetze gelten, wie beispielsweise das Landesdatenschutzgesetz Niedersachsen. Personenbezogene Behandlungsdaten, die bei Ärzten in Hausarztpraxen entstehen, unterliegen den Vorschriften der DSGVO und ergänzend dem BDSG. 5.2 Verarbeitung von Primärdaten der Arztpraxis Für die Umsetzung des Forschungsprojekts wird zudem die Betriebsstättennummer (BSNR) der behandelnden Arztpraxis erhoben und in pseudonymisierter Form in der Forschungsdatenbank gespeichert. Da durch die BSNR die Arztpraxis und damit im Regelfall auch ein Arzt als natürliche Person eindeutig durch die Kassenärztliche Vereinigung und weitere Abrechnungsinstitute identifiziert werden kann, handelt es sich um eine personenbezogene Information. Entsprechend ist für die Verarbeitung eine Rechtsgrundlage zu benennen. Beispielsweise kann für das Land Niedersachsen auf die Einwilligung gemäß § 25 Abs. 2 Nr. 1 LDSG Niedersachsen verwiesen werden, wenn es um die Verarbeitung der Daten durch eine öffentliche Stelle des Landes Niedersachsen geht. Falls der Arzt seine Einwilligung an der Teilnahme am Projekt widerruft, richtet sich das Vorgehen für die BSNR nach Kap. 7.5.2. 5.3 Verarbeitung von Sekundärdaten (Forschungsdaten) In Abgrenzung zu den durch die Behandlung entstandenen Primärdaten werden zur Umsetzung des Projekts Forschungsdaten generiert. Diese sind pseudonym und damit noch personenbezogen. 9 Die Rechtsgrundlagen im Bereich des Datenschutzrechts wurden aufgrund der ab Mai 2018 geltenden EU- Datenschutzgrundverordnung angepasst. 13.02.2020 /
Von den vorhandenen Behandlungsdaten des Patienten (Primärdaten) werden noch in der Arztpraxis
(vgl. Kap. 7.1) die identifizierenden Daten abgetrennt. Diese werden an die THS übermittelt, die sie
pseudonymisiert.
Pseudonyme Daten zeichnen sich dadurch aus, dass die identifizierenden Merkmale durch einheitliche
Kennzeichen (Pseudonyme) ersetzt wurden. Die identifizierenden Merkmale der pseudonymen
Forschungsdaten werden ausschließlich bei der THS gespeichert, so dass ein Zugriff anderer Stellen
ausgeschlossen ist (vgl. Kap. 9.4)
Wie bereits beschrieben, werden auch die BSNR pseudonymisiert. Hierfür ist ebenfalls eine
entsprechende Einwilligung des Arztes erforderlich.
Die erfolgreiche Pseudonymisierung ändert nichts an der Personenbezogenheit der Daten, so dass sie
weiterhin den Vorschriften des Datenschutzes unterliegen. Entsprechend ist hier eine Rechtsgrundlage
für die Verarbeitung zu nennen. Die Nutzung pseudonymer Forschungsdaten des Patienten und der
BSNR der Ärzte ist auf Basis einer Einwilligung beispielsweise für eine öffentliche Stelle des Landes
Niedersachsen nach § 25 Abs. 2 Nr. 1 LDSG Niedersachsen zulässig.
5.4 Einwilligungserklärung
Die Daten von Patienten und Arzt werden im Projekt und in der geplanten Nachnutzung auf Grundlage
von Einwilligungen erhoben.
5.4.1 Allgemeine Bestandteile einer Einwilligungserklärung
Folgende Inhalte sind für eine wirksame Einwilligungserklärung nach derzeitiger Rechtslage u. a.
erforderlich:
• Behandlungsdaten werden vom Gesetz als „Gesundheitsdaten“ besonders geschützt. Die
Erklärung muss sich ausdrücklich auf die Verarbeitung dieser Datenarten beziehen (vgl. z. B. § 51
Abs. 5 BDSG und Art. 9 Abs. 2 a) EU-DSGVO),
• Der Patient bzw. Arzt kann ohne Angabe von Gründen, seine Einwilligungserklärung jederzeit
widerrufen (vgl. z. B. § 4 Abs. 2 S. 5 LDSG Niedersachsen, Art. 7 Abs. 3 EU-DSGVO, § 51 Abs. 3
BDSG vgl. Kap. 7.4).
• Die Einwilligungserklärung sollte aus Gründen des besseren Nachweises schriftlich eingeholt
werden (Art. 7 Abs. 1 und 2 EU-DSGVO, § 4 Abs. 2 Satz 1 LDSG Niedersachsen,).
• Die Erklärung des Betroffenen muss freiwillig erfolgen, er muss ausreichend informiert werden.
Zudem muss er über seine Rechte (Art. 13 ff.EU- DSGVO) informiert werden. Die Erklärung muss
unmissverständlich sein und die Verarbeitung muss sich auf einen bestimmten Zweck und eine
bestimmte Datenverarbeitung beziehen (vgl. z. B. § 51 BDSG und Art. 4 Nr. 11 EU-DSGVO, Art. 13
Abs. 1 und 2, Art. 7 EU-DSGVO).
• Die betroffene Person ist zudem über die ihr zustehenden Rechte nach der EU-DSGVO in der
Einwilligungserklärung zu informieren (vgl. Art. 13 Abs. 2 lit. b EU-DSGVO).
13.02.2020 /• Für den Bereich der wissenschaftlichen Forschung sind einige Ausnahmen von diesen Rechten in
Art. 89 Abs. 2 EU-DSGVO vorgesehen. Im BDSG sind diese Ausnahmen in Bezug auf das Recht auf
Auskunft (Art. 15), auf Berichtigung (Art. 16), auf Einschränkung der Verarbeitung (Art. 19) und
Widerspruch (Art. 21) für wissenschaftliche Forschungsvorhaben aufgenommen worden, „wenn
die Verwirklichung der Forschungszwecke unmöglich gemacht oder ernsthaft beeinträchtigt
wird“ (vgl. § 27 Abs. 2 BDSG). In manchen Landesdatenschutzgesetzen sind solche Ausnahmen
für die Forschung vorgesehen, wie beispielsweise in § 13 Landesdatenschutzgesetz
Niedersachsen.
• Das Recht auf Datenübertragbarkeit (Art. 20 EU-DSGVO), also die Möglichkeit des Patienten die
von ihm selbst bereitgestellten Daten in einem strukturierten, gängigen und maschinenlesbaren
Format zu erhalten, ist ggf. im Rahmen des Projekts einzuhalten.
5.4.2 Breite Zweckbeschreibung
Wesentlich für die Wirksamkeit von Einwilligungserklärungen sind die der Verarbeitung
zugrundeliegenden Datennutzungszwecke (vgl. z. B. § 6 Abs. 1 LDSG Niedersachsen). Eine Festlegung
auf einen oder mehrere konkrete Zwecke der Datenverarbeitung kann jedoch gerade im Bereich der
wissenschaftlichen Versorgungsforschung schwierig sein: Wie in Kap. 2.1. beschrieben sollen
unterschiedliche, noch nicht abschließend beschreibbare Fragestellungen mit den Daten im Projekt
untersucht werden. Bei der Betrachtung der medizinischen Routinedaten von Patienten entwickeln
sich die wissenschaftlichen Fragestellungen erst nach Projektbeginn in eine bestimmte Richtung. Sie
entstehen beispielsweise in Abhängigkeit von bestimmten Erkrankungen, dem regionalen
Versorgungsangebot oder dem Verhalten von Patienten.
Aufgrund dieser Rechtslage hat sich für informierte Einwilligungen ein Vorgehen auf Grundlage einer
„breiten Zweckbeschreibung“ („broad consent“) entwickelt, das die TMF im Rahmen ihrer generischen
Datenschutzkonzepte10 für die medizinische Forschung entwickelt hat. Dieser Ansatz wird bereits seit
einigen Jahren für das Feld der Versorgungsforschung verwendet.11
5.4.3 Breite Zweckbeschreibung nach EU-DSGVO
Dieses Institut der „breiten Zweckbeschreibung“, als Unterfall der informierten Einwilligung findet sich
nun auch im Erwägungsgrund 33 der EU-DSGVO, der ab 25. Mai 2018 als Auslegungshilfe zu Art. 89
EU-DSGVO heranzuziehen ist, wieder:
10
Pommerening, K., Drepper, J., Helbing, K., Ganslandt, T., Leitfaden zum Datenschutz in medizinischen
Forschungsprojekten - Generische Lösungen der TMF 2.0. 2014, Medizinisch Wissenschaftliche
Verlagsgesellschaft, Berlin.
11
So zeigt ein Blick auf die Einwilligungserklärungen der NAKO Gesundheitsstudie, dass unterschiedliche
Gesundheitsdaten zur Erforschung „häufiger Krankheiten, wie Herz-, Kreislauf- und Gefäßerkrankungen,
Dieabetes mellitus („Zuckerkrankheit“), Krebserkrankungen, neurologische Erkrankungen,
Atemwegserkrankungen und Infektionserkrankungen“ im Rahmen unterschiedlicher Einwilligungserklärungen
wirksam genutzt werden dürfen. Vgl: http://nako.de/wp-
content/uploads/2016/03/NAKO_Einwilligungserkla%CC%88rung_Level-2_v2.1.2_2016-02-09.pdf, letzter
Zugriff am 26.07.2017.
13.02.2020 /„Oftmals kann der Zweck der Verarbeitung personenbezogener Daten für Zwecke der wissenschaftlichen Forschung zum Zeitpunkt der Erhebung der personenbezogenen Daten nicht vollständig angegeben werden. Daher sollte es betroffenen Personen erlaubt sein, ihre Einwilligung für bestimmte Bereiche wissenschaftlicher Forschung zu geben, wenn dies unter Einhaltung der anerkannten ethischen Standards der wissenschaftlichen Forschung geschieht. Die betroffenen Personen sollten Gelegenheit erhalten, ihre Einwilligung nur für bestimme Forschungsbereiche oder Teile von Forschungsprojekten in dem vom verfolgten Zweck zugelassenen Maße zu erteilen.“ Voraussetzung für eine breitere Zweckbeschreibung ist daher, dass sich das Vorhaben in einem bestimmten Bereich der wissenschaftlichen Forschung abspielt und anerkannte ethische Standards der wissenschaftlichen Forschung (und damit einhergehend technische und organisatorische Schutzmaßnahmen) eingehalten werden.12 Die anerkannten ethischen Standards wie die Denkschrift der DFG zur Sicherung der guten wissenschaftlichen Praxis13 und die Deklaration von Helsinki14 sind einzuhalten. 5.5 Entbindung von der ärztlichen Schweigepflicht Der Patient muss seinen ihn behandelnden Arzt von der ärztlichen Schweigepflicht entbinden, da die bei der medizinischen Behandlung anfallenden Gesundheitsdaten neben dem allgemeinen Datenschutzrecht auch dem ärztlichen Berufsrecht, wie z. B. der ärztlichen Schweigepflicht (vgl. § 9 Musterberufsordnung Ärzte), unterliegen. Die Strafnorm des § 203 StGB sieht eine Strafbarkeit behandelnder Ärzte vor, wenn sie die ihnen anvertrauten Informationen an Dritte unbefugt offenbaren. Befugnisse zum Offenbaren sind z. B. durch entsprechende gesetzliche Grundlagen oder durch eine entsprechende Erklärung des Patienten (Entbindungserklärung) einzuholen. Zu den Dritten gehören nach derzeitiger Rechtslage alle in diesem Datenschutzkonzept vorgesehenen datenverarbeitenden Stellen (vgl. Kap. 3). Die Entbindung wirkt also gegenüber der koordinierenden Stelle, der THS und dem Datenzentrum. Diese Erklärung kann entweder konkludent im Rahmen der informierten Einwilligung oder separat schriftlich erteilt werden (vgl. Kap. 5.5). Separate Schweigepflichtentbindungserklärungen werden im Regelfall im Original in der Praxis in der Obhut des entbundenen Arztes verwahrt. Sie können ebenso 12 siehe hierzu auch: DSK Beschluss der 97. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder zu Auslegung des Begriffs „bestimmte Bereiche wissenschaftlicher Forschung“ im Erwägungsgrund 33 der DS-GVO. 2019. Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder - Datenschutzkonferenz (DSK), 3.4.2019, https://www.datenschutzkonferenz- online.de/media/dskb/20190405_auslegung_bestimmte_bereiche_wiss_forschung.pdf (Abruf: 2019-05-21). 13 http://www.dfg.de/download/pdf/dfg_im_profil/reden_stellungnahmen/download/empfehlung_wiss_praxis _1310.pdf, letzter Zugriff am 26.07.2017. 14 verabschiedet von der 18.WMA-Generalversammlung, Juni 1964 Helsinki (Finnland): http://www.bundesaerztekammer.de/fileadmin/user_upload/Deklaration_von_Helsinki_2013_DE.pdf, letzter Zugriff am 26.07.2017. 13.02.2020 /
wie die informierten Einwilligungserklärungen jederzeit von dem Patienten widerrufen werden (vgl.
Kap. 7.4.1).
Inwieweit das Gesetz zur Neuregelung des Schutzes von Geheimnissen bei der Mitwirkung Dritter an
der Berufsausübung schweigepflichtiger Personen15 an der erforderlichen Entbindungserklärung etwas
ändert, ist in künftigen Projekten zu evaluieren. § 203 Abs. 3 StGB-neu ermöglicht es, dass Ärzte
„fremde Geheimnisse gegenüber sonstigen Personen offenbaren, die an ihrer beruflichen oder
dienstlichen Tätigkeit mitwirken, soweit dies für die Inanspruchnahme der Tätigkeit der sonstigen
mitwirkenden Personen erforderlich ist“. Entscheidend ist also für das zulässige Offenbaren an die
„sonstige mitwirkende Personen“, dass sie an der beruflichen Tätigkeit mitwirkt.
5.6 Zuständigkeit der Ethik-Kommission
Um die Einhaltung der berufsrechtlichen und berufsethischen Vorschriften sicherzustellen, wird die für
koordinierende Stelle zuständige Ethik-Kommission zur Einhaltung der ethischen und rechtlichen
Aspekte nach (hier die Rechtsgrundlage einfügen, beispielsweise§ 15 Abs. 1 Berufsordnung der
Ärztekammer Niedersachsen16) vor Beginn der Durchführung des Projekts beraten.
15
BR Drucksache 163/17, In Kraft treten des Gesetzes voraussichtlich im Oktober 2017.
16
https://www.aekn.de/fileadmin/media/Downloadcenter/Arzt-und-
Recht/Berufsrecht/BO_komplett_01022016.pdf, letzter Zugriff am 16.10.2017.
13.02.2020 /6 Daten und Datenkategorien Im Folgenden werden die im Projekt genutzten Primär- und Sekundärdaten dargestellt: 6.1 Primärdaten der Patienten Primärdaten sind die sogenannten „BDT-Daten“, da sie durch die BDT-Schnittstellen gewonnen werden: Die Behandlungsdatentransfer-Schnittstelle (BDT-Schnittstelle) ist eine obligate Software- Schnittstelle in deutschen Arztpraxisinformationssystemen (AIS) und gehört zur Familie der xDT- Schnittstellen (Abrechnungsdaten-Transfer, ADT; Laboradaten-Transfer, LDT; Gerätedaten-Transfer, GDT; u. a.)17. Alle xDT-Formate, so auch BDT, haben eine gemeinsame, textorientierte Syntax, in der jedes Feld als eine Zeile in eine Datei geschrieben wird. Spezifiziert aus einem Feldverzeichnis können unterschiedliche Nachrichtenklassen jeweils aus obligatorischen und optionalen Felder zusammengesetzt werden. BDT wurde entwickelt, um den Austausch kompletter Datensätze zwischen Arztpraxisinformationssystemen verschiedener Hersteller zu ermöglichen. Je nach Verfügbarkeit im Arztpraxisinformationssystem bildet ein vollständiger BDT-Export somit den kompletten Umfang des BDT- Feldverzeichnisses ab. Die Extraktion der BDT-Daten aus dem jeweiligen AIS erfolgt durch die Praxismitarbeiter, die dabei im Bedarfsfall durch einen IT-Mitarbeiter unterstützt werden. Dieser IT-Mitarbeiter steht als Experte für die Anwendung der Projektsoftware den Praxismitarbeitern während des BDT-Daten- Extraktionsprozesses in der Praxis vor Ort zur Verfügung. 6.1.1 Identitätsdaten (IDAT) Noch jeweils in der Praxis werden aus den BDT-Daten zwei getrennte Teilmengen als sekundäre Datensätze, die sogenannten „Identifizierenden Daten (IDAT)“ und die „Medizinischen Daten (MDAT)“ erzeugt. Die IDAT sind eine Teilmenge der BDT-Daten bestehend aus den Feldern Patientenname, Patientenvorname, Patientengeburtsdatum, Patientengeschlecht und der praxisinternen Identifikationsnummer. Zudem gehören die Adressdaten der Patienten dazu, die für den späteren Fragebogenversand benötigt werden. Diese IDAT werden gemeinsam mit dem Arztpraxispseudonym im gesicherten Verfahren an die Treuhandstelle (THS) übermittelt, so dass keine anderen Partner im Projekt Zugang zu diesen Daten erhalten. 6.1.2 Medizinische Daten (MDAT) Die MDAT sind eine Teilmenge der BDT-Daten, die von allen Merkmalen befreit wurden, die Patienten oder Dritte direkt identifizieren könnten. Die MDAT enthalten daher in der Regel nur Informationen, 17 BDT-Satzbeschreibung - Schnittstellenbeschreibung zum systemunabhängigen Datentransfer von Behandlungsdaten. Version 02/94. Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik Deutschland, Köln 1994. Die gegenwärtig (2017) in allen deutschen AIS genutzte Version wurde zuletzt 1994 vom Zentralinstitut für die Kassenärztlicher Versorgung, Köln, definiert, „… um den Austausch der vollständigen Behandlungsdokumentation aller Patienten zwischen verschiedenen Praxis-Software-Systemen zu ermöglichen.“ 13.02.2020 /
wie Befunde und Diagnosen und keine direkt identifizierenden Merkmale wie z. B. Geburtsdatum, Geburtsort oder Ähnliches. Eine indirekte Identifizierung, z. B. mit Hilfe eines Abgleichs mit anderen Daten, ist aber mit diesen Daten durchaus möglich. Insofern gelten auch diese Daten im datenschutzrechtlichen Sinn noch als personenbeziehbar. Die Auswahl eines BDT-Feldes als MDAT erfolgt nach folgender Einwahlliste: Nr. Feldkennung Feldinhalt Verarbeitung im Projekt 1 0202 Praxistyp 2 0204 Arztgruppe verbal 3 0206 PLZ und Ort der Praxis 4 0225 Anzahl Ärzte 5 3103 Geburtsdatum des Patienten Geburtsjahr des Patienten 6 3110 Geschlecht des Patienten 7 3649 Dauerdiagnosen ab Datum 8 3650 Dauerdiagnosen 9 3651 Dauermedikamente ab Datum 10 3652 Dauermedikamente 11 4101 Quartal der Abrechnung 12 4105 Geschäftsstelle 13 4107 Abrechnungsart (Schein) 14 4121 Gebührenordnung 15 5000 Leistungstag 16 5001 GNR/GNR-Ident 17 6000 Abrechnungsdiagnose 18 6001 ICD-Schlüssel 19 6200 Tag der Speicherung von Behandlungsdaten 20 6205 Aktuelle Diagnose 21 6210 Medikament verordnet auf Rezept 22 6211 Außerhalb Rezept verordnetes Medikament 23 6215 Ärztemuster 24 6220 Befund 25 6221 Fremdbefund 26 6222 Laborbefund 27 6225 Röntgenbefund 28 6260 Therapie 29 6265 Physikalische Therapie 30 6280 Überweisung Inhalt 31 6285 AU Dauer 32 6286 AU wegen 33 6290 Krankenhauseinweisung, Krankenhaus 34 6291 Krankenhauseinweisung wegen 35 8401 Befundart 36 8410 Test-Ident 37 8411 Testbezeichnung 38 8420 Ergebnis-Wert 39 8421 Einheit 13.02.2020 /
Diese MDAT werden im gesicherten Verfahren an die datenhaltende Einrichtung (Datenzentrum)
übermittelt.
6.1.2.1 Re-Kontaktierung des Patienten
Nach von der koordinierenden Stelle festgelegten Kriterien können einzelne Patienten rekontaktiert
werden, soweit sie entsprechend dazu eingewilligt haben. Hierzu wird ein validierter Fragebogen
verwendet, welcher den Patienten durch die THS zugesandt wird (vgl. Kap. 7.6).
6.2 Primärdaten der Arztpraxis
Wie bereits beschrieben, soll auch die Betriebsstättennummer der behandelnden Arztpraxis, bei
Vorliegen der entsprechenden Einwilligung des Arztes, an die THS übermittelt und dort
pseudonymisiert werden.
6.2.1 Betriebsstättennummer
Die Betriebsstättennummer ist eine neunstellige Nummer, die für eine Arztpraxis vergeben wird und
welche die ordnungsgemäße ärztliche Abrechnung ermöglicht. Sie identifiziert die Arztpraxis als
leistungsabrechnende Einheit.
6.3 Pseudonyme Sekundärdaten für die Forschung
6.3.1 Pseudonymisierung der IDATs der Patienten
Für die Umsetzung werden aus den vorgenannten IDATs des Patienten bei der THS Pseudonyme
generiert. Die generierten pseudonymen Sekundärdaten werden in einer Datenbank bei dem
Datenzentrum gespeichert und können dort für unterschiedliche Forschungsfragen (vgl. Kap. 2) durch
die koordinierende Stelle ausgewertet werden.
Die generierten Pseudonyme werden außerhalb der THS zu keinem Zeitpunkt mit den
identifizierenden Merkmalen verknüpft oder gemeinsam gespeichert. Die IDATs sind ausschließlich bei
der Treuhandstelle gespeichert und dürfen nur für im Treuhandvertrag festgelegten Zwecke durch die
THS genutzt werden.
Das Vorgehen zum Widerruf wird in Kap. 7.4. beschrieben.
6.3.2 Pseudonymisierung der Betriebsstättennummern der Hausarztpraxen
Für die Auswertung hausärztlicher Routinedaten ist eine Rückführung zu der entsprechenden Praxis,
sehr wichtig. Dafür gibt es drei wesentliche Gründe:
• die statistische Berücksichtigung von Praxis-Effekten bzw. Korrektur für manche
Praxiseigenschaften,
• die Rekrutierung von geeigneten Praxen für Forschungsprojekte,
• sowie die Möglichkeit eines praxisbezogenen Feedbacks (mit oder ohne Benchmarking) als
Incentive oder zu Qualitätssicherungszwecken.
13.02.2020 /Erstens ist die Praxis das lokale Zentrum der Behandlung bzw. Datenerstellung und sollte in Auswertungen (sog. Multi-Level Analysen) als übergeordnete Ebene berücksichtigt werden. Es soll also klar sein, welche Patienten in der gleichen Praxis behandelt worden sind. Es werden die Betriebsstättennummern (BSNR) der Hausarztpraxen als IDAT exportiert und über die THS pseudonymisiert. Da die BSNR eine einmalige Kennung ist und ohne großen Aufwand zu der jeweiligen Praxis zurückgeführt werden könnte, darf diese BSNR nicht in der Forschungsdatenbank aufgeführt werden. Stattdessen erzeugt die THS eine zufällige Kennung (Pseudonym) als Praxis-ID-PSN und stellt diese zusätzlich für die Speicherung zusammen mit dem MDAT-Datensatz und dem jeweiligen Forschungs-PSN des Patienten in dem Datenzentrum bereit. Bei dem Widerruf des Arztes wird die Zuordnung zwischen dem Pseudonym und der BSNR bei der THS gelöscht (vgl. Kap. 7.4.2). 13.02.2020 /
7 Beschreibung der datenbezogenen Prozesse 7.1 Grundlegende datenbezogene Prozesse Die Kommunikationsprozesse sind in Abbildung 1 dargestellt. Die einzelnen Schritte werden im Folgenden beschrieben: 13.02.2020 /
1. Der Export von BDT-Daten aus dem AIS heraus auf einen USB-Stick („BDT Store“ gemäß
Abbildung: Zwischenspeicher der Daten; siehe auch Abschnitt 7.3) wird von einem Mitarbeiter
der Praxis durchgeführt. Ergebnis: Die BDT-Daten sind sicher auf dem Zwischenspeicher abgelegt.
2. Zwischenschritt: Das BDT-Verarbeitungsprogramm („BDT Tool“ gemäß Abbildung; siehe hierzu
auch Abschnitt 7.3) wird von einem Mitarbeiter der Praxis von einem zweiten USB-Stick aus
gestartet. Eingangsvoraussetzung: Beide USB-Sticks, BDT Store und BDT Tool, sind an einen
Rechner mit Internetzugang angeschlossen. Ergebnis: Das BDT Tool kann mit der Verarbeitung
der BDT-Daten beginnen.
3. Das BDT Tool verarbeitet seriell einen BDT-Datensatz nach dem anderen. In der Abbildung ist der
Ablauf nur für einen Datensatz gezeigt. Eingangsvoraussetzung: Siehe Schritt 2. Ergebnis: Ein
BDT-Datensatz ist zur weiteren Verarbeitung im Hauptspeicher des Rechners, an den BDT Store
und BDT Tool angeschlossen sind, verfügbar.
4. Das BDT Tool erzeugt basierend auf dem in Schritt 2 eingelesenen BDT-Datensatz den
zugehörigen IDAT-Datensatz. Eingangsvoraussetzung: Schritt 2 ist erfolgreich abgeschlossen
worden. Ergebnis: Der zum BDT Datensatz zugehörige IDAT-Datensatz ist im Hauptspeicher des
Rechners verfügbar.
5. Das BDT Tool sendet eine Session-Anfrage an die THS (im Folgenden „THS Dispatcher“ gemäß
Abbildung genannt). Im weiteren Verlauf wird generell davon ausgegangen, dass derartige
Anfragen erfolgreich sind. Zur Fehlerbehandlung findet sich eine Anmerkung am Ende dieses
Abschnitts. Eingangsvoraussetzungen: Die Verbindung zwischen dem Rechner in der Praxis und
dem THS Dispatcher kann aufgebaut werden. Ergebnis: Die Session ist aufgebaut und per Session-
ID referenzierbar.
6. In diesem Schritt bezieht das BDT Tool ein sogenanntes Token für die weiteren Prozessschritte.
Beim Aufruf der requestToken() Methode wird der Parameter Type:AddPatient übergeben, um
im nächsten Prozessschritt dann bei der Treuhandstelle den IDAT registrieren zu können.
Eingangsvoraussetzung: Session ist aufgebaut, SessionID ist vorhanden. Ergebnis: BDT Tool erhält
Token.
7. Das BDT Tool übergibt dem THS Dispatcher den IDAT mittels des Aufrufes der Methode
addPatient(). Eingangsvoraussetzung: Das BDT Tool hat das Token erhalten. Ergebnis: Das BDT
Tool erhält ein Pseudonym für den Patienten, der in der aktuellen Session registriert wurde
(genannt „AIS-PSN“).
8. Im 7. Schritt wird die Verbindung AIS-PSN Pseudonym zum Patienten innerhalb der Praxis
hinterlegt. In der Regel wird dieser Schritt nur einmal pro Durchlauf (also nicht pro Datensatz)
durchgeführt und resultiert in einer Liste von Pseudonymen und Namen. Er ist u. a. für das
Consent Management innerhalb der Praxis notwendig. Eingangsvoraussetzung: Mindestens ein
AIS-PSN wurde generiert. Ergebnis: Liste mit AIS-PSN Pseudonymen und Patientennamen. Diese
verbleibt in der Praxis.
9. Das BDT Tool erzeugt basierend auf dem in Schritt 2 eingelesenen BDT-Datensatz den
zugehörigen MDAT. Eingangsvoraussetzung: Schritt 2 ist erfolgreich abgeschlossen worden und
das zum Datensatz gehörige AIS-PSN Pseudonym liegt dem BDT Tool vor. Ergebnis: Der zum BDT
Datensatz zugehörige MDAT ist im Hauptspeicher des Rechners verfügbar.
10. In diesem Schritt bezieht das BDT Tool ein weiteres Token. Beim Aufruf der requestToken()
Methode wird in diesem Fall der Parameter Type:RequestPSN übergeben, um im nächsten
Prozessschritt ein weiteres Pseudonym zu beziehen. Eingangsvoraussetzung: Session ist
aufgebaut, SessionID ist vorhanden. Ergebnis: BDT Tool erhält Token.
13.02.2020 /11. Das BDT Tool bezieht vom THS Dispatcher mittels des Aufrufes der Methode requestPSN() ein
weiteres, temporäres Pseudonym, welches zur weiteren Verwendung durch das Data
Management benötigt wird. Eingangsvoraussetzung: Das BDT Tool hat das zweite Token erhalten.
Ergebnis: Das BDT Tool erhält ein weiteres Pseudonym (genannt „Temp-PSN“).
12. Das BDT Tool erzeugt einen Container, der den MDAT und das Temp-PSN Pseudonym enthält.
Eingangsvoraussetzung: MDAT und Temp-PSN Pseudonym sind erzeugt worden und verfügbar.
Ergebnis: Der Container ist erzeugt und im Hauptspeicher des Rechners verfügbar.
13. Das BDT Tool verschlüsselt den Container mit dem öffentlichen Schlüssel des Data Managements.
Eingangsvoraussetzung: Der Container ist verfügbar. Ergebnis: Der Container liegt verschlüsselt
im Hauptspeicher des Rechners.
14. Das BDT Tool versendet den verschlüsselten Container an das Data Management, das im
Datenzentrum betrieben wird. Nach Abschluss dieses Schrittes wird entweder der nächste BDT-
Datensatz beginnend mit Schritt 3 verarbeitet oder, sofern der letzte BDT-Datensatz bearbeitet
wurde, wird das BDT Tool kontrolliert beendet. Durch die automatische Speicherbereinigung
werden alle im Hauptspeicher gespeicherten Daten verworfen. Eingangsvoraussetzung: Der
verschlüsselte Container ist verfügbar. Ergebnis: Der Container ist an das Data Management
übergeben.
15. Das Data Management entschlüsselt den verschlüsselten Container mit seinem privaten
Schlüssel. Eingangsvoraussetzung: Die Datenübertragung des Containers wurde erfolgreich
abgeschlossen und der verschlüsselte Container wurde unverändert übertragen.
16. Das Data-Management sendet eine Session-Anfrage an den THS Dispatcher.
Eingangsvoraussetzungen: Die Verbindung zwischen dem Data Management und dem THS
Dispatcher kann aufgebaut werden. Ergebnis: Die Session ist aufgebaut und per Session-ID
referenzierbar.
17. In diesem Schritt bezieht das Data Management ein Token vom THS Dispatcher. Beim Aufruf der
requestToken() Methode wird in diesem Fall der Parameter Type:RequestPSN übergeben, um im
nächsten Prozessschritt ein Pseudonym zu beziehen. Eingangsvoraussetzung: Session ist
aufgebaut, SessionID ist vorhanden. Ergebnis: Data Management erhält Token.
18. Das Data Management bezieht vom THS Dispatcher mittels des Aufrufes der Methode
requestPSN() ein Pseudonym, welches zur Speicherung der Daten in der Datenbank verwendet
wird. Eingangsvoraussetzung: Schritt 17. wurde erfolgreich abgeschlossen. Ergebnis: Das Data
Management erhält ein Pseudonym (genannt „DB-PSN“).
19. Das Data Management erzeugt einen Datenbankeintrag in der Datenbank (in der Abbildung mit
„Database“ bezeichnet). Dabei werden die MDAT zusammen mit dem DB-PSN Pseudonym
gespeichert.
Die obige Darstellung der Kommunikationsprozesse stellt die Fehlerbehandlung nicht dar. Generell
kann im Rahmen der IT-gestützten Datenverarbeitung auch bei größtmöglicher Sorgfalt bei der
Programmierung und standardkonformen technischen sowie organisatorischen Maßnahmen der
Fehlerfall nicht gänzlich ausgeschlossen werden. Es gilt daher, das Risiko eines solchen Fehlerfalls zu
minimieren, die entsprechenden Maßnahmen dazu finden sich in Abschnitt 9. Bei der
Fehlerbehandlung durch die eingesetzte Software werden die aktuellen Best Practices angewendet,
um sicherzustellen, dass im Fehlerfall
• keine Daten außerhalb der verschlüsselten USB-Sticks zugreifbar bleiben,
13.02.2020 /• dass der Fehler bestmöglich dokumentiert wird, um ihn im Nachgang nachvollziehen zu können,
und
• dass die Nutzer in den Praxen bestmöglich informiert, geschult und durch einen IT-Mitarbeiter
der koordinierenden Stelle unterstützt werden.
7.2 Austausch von Pseudonymen zwischen den Verantwortlichen
Zur Verdeutlichung der verschiedenen Pseudonyme während des Kommunikationsprozesses dient die
folgende Abbildung 2. Die Abbildung 2 zeigt in nummerierter Reihenfolge den Datenaustausch den
beteiligten Stellen. Patientenweise werden identifizierende Patientendaten (IDAT) sicher an den
Datentreuhänder übermittelt (vgl. Ziffer 1.) und mit einem Patienten -Arztpraxisinformationssystem-
Pseudonym (AIS-PSN) und einem temporären Pseudonym (Temp-PSN) beantwortet (vgl. Ziffer 2, 3, 4.).
Ausgewählte medizinische Daten (MDAT) des Patienten werden anschließend verknüpft mit dem
Temp-PSN vom BDT-Tool an das Datenmanagement sicher versendet (vgl. Ziffer 5.). Das
Datenmanagement tauscht im letzten Schritt das Temp-PSN (vgl. Ziffer 6.) gegen ein
Forschungsdatenbank-Pseudonym (DB-PSN) beim Datentreuhänder ein (vgl. Ziffer 7.). In der Arztpraxis
liegt nach der Verarbeitung nur das AIS-PSN vor, das BDT-Tool speichert selber keinerlei Daten, dem
Datentreuhänder liegen IDAT, AIS-PSN, Temp-PSN und DB-PSN vor und das Datenmanagement
speichert MDAT und DB-PSN.
7.3 Datenbezogene Prozesse für die Umsetzung in der Arztpraxis
Arztpraxen, die zugestimmt haben, am Projekt teilzunehmen, erhalten eine Anleitung zum Verfahren
der Datenerfassung, zwei USB-Sticks zur Datenverarbeitung sowie eine technische Unterstützung vor
Ort durch den IT-Mitarbeiter der koordinierenden Stelle. Einer der USB-Sticks dient als sicherer
13.02.2020 /Zwischenspeicher der Daten innerhalb der Praxis und ist verschlüsselt, der zweite USB-Stick enthält eine Software zur datenschutzkonformen Verarbeitung und dem sicheren Versand der Daten. Der an dem Projekt teilnehmende Arzt rekrutiert Patienten und dokumentiert ihre Bereitschaft an der Studienteilnahme in einer Einwilligungserklärung (auf Papier). Um später bei der Verarbeitung der BDT-Daten nur diejenigen Daten der Patienten zu verarbeiten, die eingewilligt haben, wird mithilfe des BDT-Verarbeitungsprogramms auf dem Software-USB-Stick eine Patienten-Einwilligungsliste erstellt. Das Verarbeitungsprogramm erfasst dazu die in der Einwilligungserklärung gewählten Optionen zusammen mit der praxisinternen Identifikationsnummer, Vorname und Nachname des Patienten. Die Angaben sind alle der Einwilligungserklärung auf Papier zu entnehmen. Die daraus erstellte Patienten-Einwilligungsliste speichert jedoch nicht die vollen Angaben, sondern generiert lediglich eine Kennung aus den identifizierenden Daten, um den Patienten im BDT-Datensatz eindeutig identifizieren zu können. Dieses Vorgehen soll die Arbeitsschritte in der Arztpraxis erleichtern. Die elektronische Erfassung der Einwilligungserklärung kann in einem getrennten Arbeitsschritt vom BDT-Export und dem Versand der Daten erfolgen. Sind ausreichend Patienten rekrutiert, ist im Arztpraxisinformationssystem ein BDT-Daten-Export durchzuführen. Ergebnis eines Exports sind die BDT-Dateien, die anschließend in einem Verzeichnis auf einem Rechner der Praxis abgerufen werden können. Zur weiteren Verarbeitung werden die exportierten BDT-Dateien auf den sicheren USB-Speicherstick übertragen. Wird der sichere USB-Stick an einen PC angeschlossen, ist zum Öffnen des Inhalts ein Passwort zur Verschlüsselung anzugeben. Das Passwort kann frei gewählt werden und wird ab diesem Zeitpunkt für den Zugriff auf die gespeicherten Daten freigeben. Die Verarbeitung der Daten muss an einem PC durchgeführt werden, der mit dem Internet verbunden ist. An diesem Rechner wird nun der verschlüsselte USB-Stick mit den BDT-Daten und der Patientenliste angeschlossen und zusätzlich der zweite USB-Stick mit dem BDT-Verarbeitungsprogramm. Wird der verschlüsselte USB-Stick an den PC angeschlossen, so muss zur Entschlüsselung der BDT-Daten das zuvor beim BDT-Export gewählte Passwort eingeben werden. Das BDT-Verarbeitungsprogramm prüft die Exportdateien und listet alle Patienten anhand der erstellten Patienten-Einwilligungsliste auf, für die eine Verarbeitung geplant ist. Nach einer Bestätigung der Verarbeitung durch die Mitarbeiter der Arztpraxis wird aus dem gesamt BDT- Exportdateien ein gefilterter Datensatz erzeugt, in dem patientenidentifizierende Daten entfernt und mit einem Pseudonym versehen werden. Nach der Verarbeitung muss der Versand der Daten bestätigt werden. Die Daten werden verschlüsselt und in einer sicheren Verbindung in das Datenzentrum übertragen. Die BDT-Exportdateien können im Anschluss vom USB-Stick gelöscht werden. Der verschlüsselte USB- Stick kann jederzeit mit neuem Passwort für weitere BDT-Exporte im Projekt eingesetzt werden. 7.4 Datenbezogene Prozesse bei Widerrufen 7.4.1 Widerrufe des Patienten Der Patient kann seine Einwilligung jederzeit frei widerrufen. Der Widerruf kann schriftlich (Brief, Fax, Mail) oder mündlich an die koordinierende Stelle, die THS oder die ihn behandelnde Arztpraxis 13.02.2020 /
Sie können auch lesen
