Ein großer Überblick über das dezentrale Technologiefeld rund um die Nutzung einer web3-basierten Infrastruktur für Medizindaten. Enthält 30 Slides Einleitung über rechtliche Grundlagen, einer Betrachtung der TI und einer Reihe von Debattenbeiträgen.

1. ĐePA
Eine alternative dezentrale Infrastruktur
für sichere, interoperable und verwertbare
Patientendaten
https://turbinekreuzberg.com/de/depa

2. Stefan Adolf
Developer Ambassador
@stadolf
stefan.adolf@turbinekreuzberg.com
OG, MKF Leo II
3./PzBtl. 84 Lüneburg

3. “Elektronische Patientenakte”
Eine elektronische Patientenakte ist ein Vertrauensraum, in dem der Patient
vorhandene medizinische Informationen einsehen kann, die in erster Linie,
aber nicht ausschließlich von Leistungserbringern und
Versorgungseinrichtungen stammen.
Der Versicherte kann souverän entscheiden, welche Informationen in seiner
ePA zusammenlaufen, insbesondere kann er bestimmte Dokumente anfordern
und Zugangsrechte beschränken.
Ziel einer ePA ist es stets, die Qualität, Wirtschaftlichkeit und Transparenz
sowie die Qualitätskontrolle der Behandlung zu verbessern und zu
ermöglichen, dass es leichter fällt, auf die Krankenhistorie des Patienten
zuzugreifen, als im analogen Zeitalter der Aktenordner und Faxgeräte.
stadolf

4. ePA in Deutschland: Archäologie
1997
Telematik im
Gesundheitswesen -
Perspektiven der Telemedizin
in Deutschland” (Roland
Berger & Partner / BMG)
1998
“Forum 2000”: eine
ePA wäre sehr
hilfreich
2002
Bundestagsinitiative
beschließt Gesetzentwurf für
elektronische Patientenakte
2003
§291a SGB V: massive
Datenschutzbedenken
2004
GKV-Modernisierungsgesetz:
eGK als zentraler
Anknüpfungspunkt für
E-Health-Dienste
2005
Gründung der “gematik”
Gesellschaft für
Telematikanwendungen der
Gesundheitskarte mbH
2015
E-Health-Gesetz: Die Daten
sollen in der Hoheit des
Patienten liegen
2018
Am 31.12.2018 hätte die
ePA eingeführt werden
müssen.
2019
Alle Praxen müssen an die TI
angeschlossen sein
15.5. 2019: BMG wird
Mehrheitsgesellschafterin
der gematik

5. Sozialgesetzbuch (SGB V)
Fünftes Buch
Gesetzliche Krankenversicherung

6. §341 SGB V Abs 1: ePA
Die elektronische Patientenakte ist eine versichertengeführte
elektronische Akte, die den Versicherten von den Krankenkassen auf
Antrag zur Verfügung gestellt wird. Die Nutzung ist für die
Versicherten freiwillig. Mit ihr sollen den Versicherten auf
Verlangen Informationen, insbesondere zu Befunden, Diagnosen,
durchgeführten und geplanten Therapiemaßnahmen sowie zu
Behandlungsberichten, für eine einrichtungs-, fach- und
sektorenübergreifende Nutzung für Zwecke der
Gesundheitsversorgung, insbesondere zur gezielten Unterstützung
von Anamnese und Befunderhebung, barrierefrei elektronisch
bereitgestellt werden.
19.6.2020
stadolf

7. §341 SGB V Abs 2: ePA Inhalte
● Befunde, Diagnosen, Therapiemaßnahmen,
Früherkennungsuntersuchungen, Behandlungsberichte
● untersuchungs- und behandlungsbezogene medizinische
Informationen
● Medikationsplan
● Notfalldaten
● Untersuchungsheft für Kinder, Mutterpass
● Impfdokumentation
● Bescheinigung über eine Arbeitsunfähigkeit
● bei den Krankenkassen gespeicherte Daten über die in Anspruch
genommenen Leistungen des Versicherten
● Rezeptvergabe
● Zahnbonusheft
19.6.2020
DVG
DVG
DVG
DVG
DVG
Digitale
Versorgung-
Gesetz
19.12.2019
stadolf

8. ● (3) Die für die elektronische Patientenakte erforderlichen
Komponenten und Dienste werden [...] von der Gesellschaft für
Telematik zugelassen.
● (4) Die [...] Leistungserbringer haben gegenüber der
Kassenärztlichen Vereinigung nachzuweisen, dass sie [...] über die
erforderlichen Komponenten und Dienste verfügen. Wird der
Nachweis nicht bis zum 30. Juni 2021 erbracht, ist die Vergütung
vertragsärztlicher Leistungen pauschal um 1 Prozent zu kürzen [...]
● (7) Die Krankenhäuser haben sich bis zum 1. Januar 2021 mit den
[...] erforderlichen Komponenten und Diensten auszustatten und sich
an die Telematikinfrastruktur anzuschließen.
§341 SGB V: gematik 19.6.2020
stadolf

9. §306 SGB V Abs 2 Komponenten
● eine dezentrale Infrastruktur bestehend aus Komponenten zur
Authentifizierung und zur sicheren Übermittlung von Daten in die
zentrale Infrastruktur,
● eine zentrale Infrastruktur bestehend aus
○ sicheren Zugangsdiensten als Schnittstelle zur dezentralen
Infrastruktur und
○ einem gesicherten Netz einschließlich der für den Betrieb
notwendigen Dienste sowie
○ eine Anwendungsinfrastruktur bestehend aus Diensten für die
Anwendungen nach diesem Kapitel.
19.6.2020
stadolf

10. §306 SGB V: Telematikinfrastruktur
● BMG, KBV, Bundesärztekammer, die Deutsche Krankenhausgesellschaft,
die Apotheker schaffen die Telematikinfrastruktur. Eine interoperable
und kompatible Informations-, Kommunikations- und
Sicherheitsinfrastruktur, die der Vernetzung von Leistungserbringern,
Kostenträgern, Versicherten und weiteren Akteuren des
Gesundheitswesens sowie der Rehabilitation und der Pflege dient,
○ für die Nutzung weiterer Anwendungen der Telematikinfrastruktur
ohne Nutzung der elektronischen Gesundheitskarte nach § 327 und
○ für die Verwendung für Zwecke der Gesundheits- und pflegerischen
Forschung.
19.6.2020
stadolf

11. TL/DR: TI & ePA
● BRD / BMG verantwortet die TI durch die gematik
● Die Datenhoheit liegt beim Patienten
● Für den Patienten ist die Nutzung der ePA freiwillig
● LE & Krankenhäuser müssen per 1.1/6.2021 angeschlossen sein
● Ziel ist die Verwendung von Informationen in der Forschung
● Drittapplikationen (u.a. “DiGA”s) müssen von der gematik zertifiziert werden
● TI: dezentrale Authentifizierung für den Zugang zu einem
zentralen Dienstnetzwerk
stadolf

12. ePA | TI: Zahlen, Fakten,
Wahrnehmung

13. Zahlen rund um die ePA
375 600 000 000
197 000
20 000 2000
34 000 000 000
11,5
€ kostet das deutsche Gesundheitssystem jährlich.
Das sind % des BIP
€ könnten durch konsequente Digitalisierung eingespart werden
Ärzte und Zahnärzte gibt es in Deutschland
Apotheken Krankenhäuser
73 000 000 Millionen Versicherte in der GKV
105 Gesetzliche Krankenkassen (1.1.2020)
stadolf

14. Europa
Spanien: 70% der Hausärzte nutzen die ePA
Frankreich: flächendeckende Nutzung in Notaufnahmen
Dänemark: MedCom wurde 1994 eingeführt, transportiert 60 Mio Dokumente jährlich
● Nutzt persönliche ID-Nummer ab Geburt + digitale Signatur
● „Danish Healthcare Data Network“ wird seit 2001 von einer
Non-Profit-Organisation betrieben
Niederlande: 89,4% aller Patientendaten digitalisiert.
● Zuständig sind 380 regionale Kommunen
● Gesundheitsdaten sind auf über 3.000 lokale ePA verteilt
Österreich: ELGA seit 12/2015 - 22,6 Mio Dokumente, 72% aller Patienten
● arztgeführt und patientenmoderiert per Handysignatur oder Bürgerkarte
● 3,3% haben von Opt-out Gebrauch gemacht
stadolf

15. gematik-Roadmap für den ePA-Rollout
stadolf

16. Telematik-Infrastruktur
von innen

17. ePA: Wo liegen die Daten?
Die Daten liegen in erster Linie bei denjenigen, die sie erstellt haben.
Ein Krankenhaus speichert seinen Aufnahmebefund in seinem
Primärsystem, der Hausarzt dokumentiert seine Behandlung mithilfe
seiner Praxissoftware und ein Labor führt Buch über die
Blutanalysen, die es erstellt hat.
Daneben verfügen die Patienten mit der ePA über einen technischen
Vertrauensraum, in dem sie einen Überblick über ihre
Gesundheitsdaten erhalten können. Aufgrund ihrer Funktion als
Dreh- und Angelpunkt lässt sich die ePA deshalb als virtuelle
Komponente in dem ansonsten verteilten System verstehen.
stadolf

18. gematik: TI für den Bürger
stadolf

19. gematik: TI für die Praxis
stadolf

20. Bundesrechnungshof: TI für MdBs
stadolf

21. Gematik: TI für Fachdienstentwickler
stadolf

22. Was ist dieser “Konnektor”?
stadolf

23. TI-Konnektoren
stadolf
Quiz: Wie teuer ist 1 (ein) SMB-C Konnektor für DIY-Kunden (Arztpraxis)?

24. TI: Konnektoren-Farm im Rechenzentrum
stadolf

25. TI: Kritik

26. PDSG: Patientendatenschutzgesetz
Erweitert §306 3 (3) Telematikinfrastruktur: 19.6.2020
Für die Verarbeitung der zu den besonderen Kategorien [...]
gehörenden personenbezogenen Daten in der Telematikinfrastruktur
gilt ein dem besonderen Schutzbedarf entsprechendes hohes
Schutzniveau, dem durch entsprechende technische und
organisatorische Maßnahmen [...] Rechnung zu tragen ist.
14.10.2020
(in Kraft)
stadolf

27. Ulrich Kelber: Bundesdatenschutzbeauftragter
stadolf

28. Stimmen zum PDSG
Netzpolitik.org
Sollte das Patientendaten-Schutz-Gesetz Anfang 2021 in Kraft
treten, müssen sich Krankenkassen entscheiden, ob sie gegen das
neue Gesetz oder die DSGVO verstoßen.
Deutsche Apotheker Zeitung
Sie [U.Kelber] sind der Auffassung, dass die Regelungen zum
Zugriffsrecht auf die elektronische Patientenakte (ePA) sowie das
Authentifizierungsverfahren nicht den Anforderungen des
europäischen Datenschutzrechts genügen. Kelber will die
Krankenkassen anweisen, die insgesamt 44,5 Millionen Versicherten
per Warntext über einen mangelnden Datenschutz zu informieren.
stadolf

29. CCC
CCC19, Martin Tschirsch & Dr med Christian
Brodowski:
“Hacker hin oder her”: Die elektronische
Patientenakte kommt!
stadolf

30. Off. Brief der KV-Vorstände an den KBV
Wir als Landesvorstände
sind nicht mehr in der
Lage, die TI mit ihrer
inzwischen unendlichen
Reihe von Pannen und
Peinlichkeiten, verbunden
mit einem Null-Nutzen,
unseren Mitgliedern weiter
zu vermitteln. Die [..]
Mitglieder in den
unterzeichnenden KVen
akzeptieren einfach die
Rahmenbedingungen der
TI-Ausgestaltung in der
derzeitigen Form nicht
mehr.
Der generelle [..] Tenor ist, dass
eine digitale Vernetzung und
ein deutlich verbesserter
Informationsaustausch
zwischen allen Beteiligten im
Gesundheitswesen begrüßt
wird, die hierfür zur Verfügung
stehende Technik in Form des
„Steinzeitkonnektors“, die
weitere Hardware, das
Management durch die
gematik, der Einfluss der
Industrie, die politischen,
gesetzgeberischen
Rahmenbedingungen und auch
die Rolle der KBV aber in keiner
Weise mehr akzeptiert wird.
Zusammenfassend ist
jetzt eine Situation der
TI-Anbindung erreicht,
die für die ärztliche und
psychotherapeutische
Basis nicht mehr
tolerierbar ist und somit
einen weiteren Baustein
im
Fruststationsbewusstsein
der Kollegen liefert.
14.7.2020
stadolf

31. Off. Brief der KV-Vorstände an den KBV
Wir fordern Sie auf,
Minister Spahn zu bitten,
durch eine
Gesetzesänderung die
Sanktionen einer nicht
stattgefundenen
TI-Anbindung bis zu dem
Zeitpunkt auszusetzen, bis
eine sichere
softwarebasierte
Vernetzungsstruktur für
die Praxen geschaffen ist.
… dem KBV/KV-System die
Möglichkeit zu geben, endlich
industrieunabhängig eigene
Lösungen für den
PVS/TI-Bereich in den
Vertragsarztpraxen zu
entwickeln und den Mitgliedern
der Landes-KVen zur
Verfügung zu stellen.
Wir sehen keine
Möglichkeit mehr für eine
Akzeptanz der TI durch
weitere
Beschwichtigungsversuche
und Teillösungsansätze als
gegeben an, ohne dass
zeitnah eine uns politisch
erheblich gefährdende
allgemeine
Verweigerungshaltung der
Ärzte stattfindet.
14.7.2020
stadolf

32. Umfragen
BITKOM Digital Health
Transformation Week
20.11.2020, ~60 qualif. Teilnehmer
stadolf

33. Umfragen
Patientenbefragung / Bachelorarbeit bei TXB
(TH Wildau, Emil Bethe), 260 Teilnehmer:innen
“Bedürfnisse von Patienten im
Hinblick auf die Einführung einer elektronischen
Patientenakte (ePA) in Deutschland”

34. Frage. Bremsen oder Gas geben?
stadolf

35. Fazit
Lt. SGB V §341 dürfen wir gar keine ĐePA bauen.
-> der Staat ist in Form der gematik damit beauftragt.
Die staatl. TI agiert als “Datenautobahn” für
“Datentreuhänder”-Applikationen der Krankenkassen
-> Idee der Sparkasse Siegen: “DatenBANK” (!)
Zitat Katharina Juenger / Founder & CEO TeleClinic:
Der Staat kann nicht den Anspruch haben, "das eine Produkt"
zu bauen - ohne Wettbewerb wird das nichts
stadolf

36. Alle haben gesagt, das geht nicht.
Bis einer kam, der das nicht wusste.
Der hats dann gemacht.

37. ĐePA
https://turbinekreuzberg.com/de/depa

38. ĐePA: Pitch
Die ĐePA ist eine dezentrale Infrastruktur für Europa, um
personenbezogene medizinische Daten zu dokumentieren und
auszutauschen.
Damit schaffen wir ein sicheres, vertrauenswürdiges und
interoperables Fundament für das Gesundheitswesen, an das sich
sämtliche Akteure und Systeme andocken können.
stadolf

39. Dezentral vs. Verteilt
Gut für die Forschung Gut für Interoperabilität & Datenschutz
TI
bdr
eGA
ĐePA

40. Dezentrale Schlüsseltechnologien
IPFS & Ethereum

41. web3

42. IPFS: Inter Planetary File System
● P2P-Netzwerk mit variablen Transportprotokollen
○ ~= CDN für den weltweiten Zugriff auf beliebige Daten
● Content Addressing
○ Content - hash -> CID
● DHT: Global verteilte Hash-Table
○ Wer kennt den Inhalt hinter einer CID?
● DAG: Content Graphs
○ Dokumente können in content-hashed
Graph-Stukturen adressiert & traversiert werden
● Resilient, Verteilt, Interoperabel, Offen
stadolf

43. IPFS: Content Addressing
Qmdq5k86F52qLTswewpVCaNVrULfv4uhrwG3UxoKttPm1C ==
bafybeihge7pzuytxi6xrhouz3az5avyyyqwdul7mqjbgar6gqoya3lkthm

44. IPFS ist ephemeral
● IPFS != Speichersystem
● Permanente Daten benötigen eine “Festplatte”
● z.B. zentral betriebene Perma-Stores
○ Pinning Services / IPFS-Cluster
○ Blockstack Gaia
○ “Bring your own harddisk” (Nextcloud)
● Besser: Dezentral inzentivierte Perma-Stores
○ Filecoin
○ Arweave
○ StorJ Tardigrade
stadolf

45. Ethereum: DLT / Blockchain-Aspekte
● “Blockchain” ~= verteiltes binäres Transaktionslog
● Verteiltes Konsensprotokoll zur Bestimmung eines aktuellen
Zustands (deterministische State-Machine)
● Inzentivierung der Konsensteilnahme (“Proof of Work / Stake”)
○ Man gewinnt etwas, wenn man zum Konsens beiträgt
○ Man verliert etwas, wenn man versucht, den Konsens zu manipulieren
● Kryptographische Verkettung von Transaktionen / Zuständen
○ Die längste valide Kette, die ich sehe, gilt als meine lokale Wahrheit
○ Inhalte in der Kette können niemals verändert werden
● Global verteilt, völlig unkontrolliert, frei zugänglich
● Utility-Token Ether zur Darstellung von Leistung (= “Geld”)
● Jeder Nutzer verwahrt den Seed für seine Private Keys in einer
Wallet seiner Wahl
○ seed -> private key -> public key -> keccak256(public key) == account address
stadolf

46. stadolf
Smart Contracts: ausführbarer Binärcode
Address
Contract Creation
Block 8928158
Transaction #
13. 11. 2019 07:17:57 PM +UTC
Contract Address
code
Address
Contract Call
Block 11092313
Transaction #
20. 10. 2020 09:57 AM +UTC
call
Wenn ich beliebige Daten in eine Transaktion schreiben kann,...
… kann ich auch Code in eine Transaktion schreiben! => EVM (2015)

47. Smart Contracts: Implikationen
● 100% unkomprimittierbarer Code
● Contracts können…
○ Zustand speichern & verändern (State)
○ Im Rahmen einer Transaktion auf Zustand reagieren
○ andere Contracts aufrufen
○ neue Contracts erzeugen
○ Wert verwahren (sie haben eine Balance)
○ Randbedingungen prüfen und Zugriff prüfen
○ Niemals “down” gehen
■ Aber sie können Fehler enthalten (Ihr Code stammt von Menschen!)
○ keine Geheimnisse behalten
stadolf

48. ĐePA 1 Systemsicht
stadolf

49. Identität
Keys, DIDs, Signaturen
SSI, Resolver, Proofs

50. Identität
Digitale Identitäten spielen eine wesentliche Rolle für ein sicheres
digitales Gesundheitswesen. Dafür muss erst organisatorisch
gewährleistet sein, dass Personen, die eine digitale Identität erhalten
sollen, überhaupt existieren.
Derzeit geschieht dies dadurch, dass man sich bei der Anmeldung
bei einer Krankenkasse einmalig ausweist und diese dann die
elektronische Gesundheitskarte (eGK) per Post an die angegebene
Wohnadresse zusendet. Endet die Gültigkeit einer Karte, kommt die
neue Karte oftmals automatisch per Post.
stadolf

51. Identität
Es ist darüber hinaus zu erwägen, ob das Nebeneinander von eGK
und der eID-Funktion des Personalausweises dauerhaft eine sinnvolle
Lösung ist – oder ob es für die Bürger nicht einfacher wäre, den
neuen Portalverbund für E-Government und die künftige
E-Health-Infrastruktur mit ein und demselben Identifizierungs- und
Authentifizierungsmerkmal zu nutzen.
Eine Handysignatur, mit der man auf die eigene ePA auch per
mobilem Endgerät zugreift, sollte in Zukunft in jedem Fall zur
Standardausstattung gehören

52. Ethereum-basierte Identität (nicht sicher ;) )
● Ethereum-Key = Identität
● Ethereum Private Key zur asym.
Verschlüsselung (ECIES)
● Patient legt Stammdaten selbst fest
● Daten werden mit dem Public Key des
Nutzers verschlüsselt
● IPFS-Ordner enthält alle Daten
● “Patientenakte” = Smart Contract unter
Kontrolle des Patienten
● Contract speichert aktuellen Stand
(CID)

53. Step 2: Selbstsouveräne, dezentrale Identität
W3C DIDs
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable,
decentralized digital identity. A DID identifies any subject (e.g., a person, organization,
thing, etc.) that the controller of the DID decides that it identifies. In contrast to typical,
federated identifiers, DIDs have been designed so that they may be decoupled from
centralized registries, identity providers, and certificate authorities.
did:3:bafyreigmowwug5zyyax4yqdes3fwukp5gi6rjjlrxculnk64izea5hnrye
https://3box.io/0x70631b7376f4956185dac1b9cb4e9f83ccbc2764/

54. SSI: DID Document (3ID)
stadolf

55. SSI mit Ethereum & IPFS
● Ethereum-Adresse ~= Hinweis auf Identität
● Signatur durch private Key ~= einfacher Nachweis der Identität
● Ableitung des Schlüsselmaterials von Ethereum-Seed
○ erlaubt Generierung einer W3C-konformen DID
○ Nachweismöglichkeit der Kontrolle über die DID
● Hinterlegung des DID Documents auf IPFS
○ = Garantierte dezentrale Auflösbarkeit des DID Documents
● Verankerung der Dokumente auf Ethereum
○ = Nachweis über Gültigkeit / Zeitstempel der Dokumente
● Verifiable Claims erlauben Nachweis von Personeneigenschaften
○ https://www.w3.org/TR/vc-data-model/#evidence
stadolf

56. Effekte dezentraler SSI
● Keine zentralen Zertifikatsdienste (OCSP)
○ Root-Zertifikate sind dezentral überprüfbar
○ Zertifikatsschlüssel müssen natürlich sicher aufbewahrt werden
● Keine zentrale Herausgabestelle von Private Keys (eGK + NFC)
○ Not your key - not your account!
● Teilnehmer bestimmen von Anfang an ihre Identität selbst
○ Krankenkassen & Verbände müssen lediglich einen KYC-Prozess anbieten
● Schlüssel müssen vom Teilnehmer verwahrt und gesichert werden
● Potenzielle Metadaten-Leaks
○ lösbar durch zkSNARK proofs, Rollups
stadolf

57. Sicherheit
Verschlüsselung
Datenaustausch
Key Rotation
Autorisierung

58. Verschlüsselung
Eine nationale E-Health-Infrastruktur muss so konzipiert und implementiert
sein, dass sich unbefugte Personen kein umfassendes Bild vom
Gesundheitszustand einer Person machen können.
● Alle Transport-Protokolle sind TLS1.3-gesichert
● ĐePA verschlüsselt Daten durch den Urheber (e2e)
● 1. Iteration (naiv)
○ Daten werden asymmetrisch für jeden Empfänger verschlüsselt
○ Wir nutzen die Ethereum-Keys der Parteien (ECIES)
● 2. Iteration
○ Daten werden symmetrisch verschlüsselt (AES / NaCL) und shared keys verteilt
○ Entzug der Leserechte bedeutet Key Rotation
● 3. Iteration
○ Nutzung des Schlüsselmaterials der DIDs
stadolf

59. Autorisierung
● Attribut-basierte Freigaben (ABAC)
○ erlaubt “feingranulares” Rechtemanagement
○ System des Patienten erstellt eine individuelle Arztkopie
○ Contract-Einstellungen legen fest, welche Datentypen freigegeben werden
○ Ziel: jeder Arzt sieht nur, was der Patient ihm freigibt
● Eigenschaften der Ziel-Identität können über Smart Contracts
geprüft werden
○ Ist ein Arzt immer noch ein Arzt?
○ Andere Parteien (“Arztregister”) können Claims der Ärzte widerrufen
■ ~ dezentrale verifizierbares “OCSP”
stadolf

60. 👍 Ulrich Kelber gefällt das.
(behaupten wir)

61. Interoperabilität

62. Interoperabilität
Referentenentwurf zum DVG
Vorgesehen ist die Verpflichtung der gematik, die Voraussetzungen dafür zu
schaffen, dass Versicherte ihre Daten bei einem Wechsel der Krankenkasse
mitnehmen können. Dadurch wäre ein weiterer Anreiz geschaffen, den
Aspekt der Interoperabilität von vornherein ernst zu nehmen und dadurch die
Gefahr von Insellösungen zu bannen
§326 SGB V
Anbieter von Betriebsleistungen oder von Komponenten und Diensten der
Telematikinfrastruktur müssen über die nach § 323 Absatz 2 und § 325 Absatz
1 erforderliche Zulassung oder über die nach § 327 Absatz 2 Satz 1
erforderliche Bestätigung verfügen, bevor sie die Telematikinfrastruktur
nutzen.
stadolf

63. Interoperabilität: web3
● web3 = interoperable, zugangsfreie Applikationen (dApps)
● IPFS = kein Gatekeeper auf Datenspeicher ( != “S3”)
● Smart Contracts = unkomprimittierbare Gatekeeper
○ Wer die ABI eines Contracts kennt, kann mit ihm interagieren
● Basis-Sicherheit (“Wallet”) wird vom Nutzer verantwortet
● Community-getriebene Governance des Systemverhaltens
○ DAOs
○ Konsortiales PoA
○ Proxy-Contracts
○ Stabilität und Zugang sind ökonomisch inzentiviert, nicht die Funktionalität
stadolf

64. Zugriffsszenarien: Patient <-> Leistungserbringer
Observation {
Category: [],
Code: {
Coding: [],
},
Subject: { reference: “” },
effDateTime: “2020-11-22”
}
}
Patient {
Identifier { }
Name {}
Address {}
Telecom {}
}
Hi, I am
Ok, my obervation is:

65. Đemo
patient.depa.digital

66. CID
Zugriffsszenarien: DiGAs / Forschung
CID
May we see your
age & headache data?
Kopfschmerz
tagebuch
ĐePA-
Contract
0x7
DiGA 0x9
Yes.
Patient
0x2
CID0x9
owns
CID0x2
CID0x2
You’re old!
Arzt 0x8
CID0x2’ok:(
CID0x9
CID0x2
Think, I have a good
Medication for you!
stadolf

67. Ökonomisierung
Pinning-Services
Konsortionales PoA
Forschungsdaten
“Health-Token”

68. Pinning-Services / Nodes
● “Festplatten im Internet” sind nicht
kostenlos.
● Auch Amazon kann unerreichbar sein
● IPFS persistiert keine Daten (nur beim
Urheber)
● kommerzielle “Pinning”-Services
können eine Lösung sein
● langfristig: dezentrale Persistenz
(Filecoin)
stadolf

69. Konsortionales PoA-Netz / Governance
● kontrollierbares, potenziell abschließbares Blockchain-Netzwerk
● Benötigt bekannte “Autoritäten”, um Konsens zu erzeugen
○ “Abstimmung” vs. “Inzentivierung” (PoS / PoW)
○ Nutzer müssen Autoritäten Vertrauen entgegenbringen
○ Autoritäten erhalten für die Validierung Netzwerk-Fees
● Ideale Autoritäten: BMG, bdr, gematik (!), KBV, Krankenhäuser
● Autoritäten können zentrale Smart Contracts einer Chain
kontrollieren
○ = in die Chain eingebautes Protokoll vs custom smart contracts
● Anschlussfähigkeit bleibt erhalten
stadolf

70. TI: ePA-Daten für die Forschung
Auf dem Weg zu einer forschungskompatiblen elektronischen Patientenakte sollen die
Aufgaben der Datentransparenz [...] von einer Vertrauensstelle und einem
Forschungsdatenzentrum durchgeführt werden
Es ist jedoch noch ein weiter Weg, bis einzelne Versicherte Daten aus ihrer ePA für
Forschungszwecke freigeben und wissenschaftlichen Einrichtungen überlassen können.
Es soll eine „Datensammelstelle“ eingerichtet werden, in der einzelne Datenbestände
zusammenfließen. Die neue Aufgabe einer Vertrauensstelle sowie eines
Forschungsdatenzentrums kann das BMG künftig einer „öffentlichen Stelle des Bundes“
übertragen. Erstere ist dafür zuständig, die übermittelten Daten zu pseudonymisieren,
während Letztere die pseudonymisierten Daten aufbereitet und an antragsberechtigte
Stellen aus der Forschung weitergibt.
Eine Grundregel muss lauten: Die Forschung mit Gesundheitsdaten muss dem Patienten
zugutekommen.
stadolf

71. TI: Vertrauen durch Treuhänder

72. ĐePA: MeReD
● Medical Research Datapool
● Angebot (Patient) <- ... -> Nachfrage (Forschung)
● Pseudonymisierung kann von Apps geleistet werden
○ Und ggf. von dezentralen Treuhändern kontrolliert
○ “Treuhänder” == Geschäftsmodell!
● Sicherheit ist inzentiviert / hängt nicht von Vertrauen ab
● Königsklasse
○ Zugang zu anonymer Nachfrage = Nutzung von Daten-Markplätzen
○ Ocean Protocol
○ Federated Learning / Homomorphic encryption
○ Rückfluss der Wertschöpfung zum Urheber (Patient / Arzt)

73. “E-Health”-Token
● Wird von Autoritäten herausgegeben (minting)
● Kann Dienstleistungen & Boni im Gesundheitssystem abbilden
● Nutzung zur Inzentivierung “gesunden” Verhaltens
● Potenziell nutzbar als Basis-Token für Abrechnungen
● Belohnung für Datenspenden / Forschungserfolge
● Problem: Stabilität und Nachvollziehbarkeit
stadolf

74. Fazit.
patient.depa.digital -- turbinekreuzberg.com/depa
● Web3: Sicherheit, Freiheit & Interoperabilität
● Verantwortung (Keys) verschiebt sich zum Patienten
● Ganze Problemklasse (Konnektoren!) wird durch die ĐePA obsolet
● Sicherheitslücken betreffen nur noch einzelne Patienten.
○ Starke e2e-Verschlüsselung ist überall Pflicht
● Persönliche Hoheit über die Daten wird maximiert
● Ermöglicht Teilhabe an und Zugang zur Forschung
● Wir sind verantwortlich, dass es funktioniert. Nicht die gematik.

75. Moral.

77. Stefan Adolf
@stadolf
stefan.adolf@turbinekreuzberg.com
https://turbinekreuzberg.com/depa
Fin.