Einwilligung ist kein Kontrollkästchen.

Die fünf technischen Invarianten

Betrachten Sie die fünf Regime aus der Perspektive eines Ingenieurs. Lässt man die Rechtssprache weg, bleibt eine Liste von fünf technischen Invarianten übrig, die die umsetzende Infrastruktur erfüllen muss. Keine davon ist optional. Keine davon kann durch vernünftige Vertragssprache wegverhandelt werden. Jede ist namentlich in primärem Recht verankert.

1. 01 Personenbezogene Bezeichner

   Der Bezeichner, den die betroffene Person kontrolliert, muss die Vertrauenswurzel sein — kein Bezeichner, der von einer vertrauenden Partei vergeben wird. EHDS Recital 54 und eIDAS 2.0 Article 5a benennen dies ausdrücklich: Die Bürgerin oder der Bürger muss handlungsfähig sein, ohne dass der Verantwortliche sie oder ihn in einem gesonderten Register nachschlagen muss. Jede Architektur, die darauf beruht, dass der Verantwortliche den Bezeichner prägt und speichert, scheitert hier von Anfang an.

2. 02 Verifizierbares, zeitgestempeltes Opt-out

   Der Widerruf muss ein kryptografisch signiertes, zeitgestempeltes Ereignis sein, das die Aufsichtsbehörde — und ein künftiges Gericht — verifizieren kann, ohne den Protokollen des Verantwortlichen vertrauen zu müssen. GDPR Article 7(3) macht dies ausdrücklich: Der Verantwortliche trägt die Beweislast. Ein Datensatz in einer internen Datenbank ist in keinem Forum, in dem der Verantwortliche Beklagter ist, als Beweis geeignet.

3. 03 Reversibilität ohne Re-Identifikation

   Recital 54 des EHDS verlangt, dass das Opt-out reversibel bleibt — die betroffene Person kann wieder einwilligen — ohne dass jemand die zugrundeliegenden Datensätze re-identifizieren muss. Dazu muss das Opt-out gegen ein Credential wirken, das das Subjekt kontrolliert, nicht gegen eine serverseitige Zuordnungstabelle. Zentralisierte Einwilligungsregister scheitern hier strukturell.

4. 04 Verantwortungsübergreifende Propagierung

   GDPR Article 17(2) und EHDS Article 71 verlangen beide, dass der Widerruf an jeden nachgelagerten Empfänger weitergeleitet wird. In der Praxis bedeutet dies, dass der ursprüngliche Verantwortliche nicht einfach seine lokale Zeile aktualisieren kann — jede Partei, die die Daten jemals erhalten hat, muss die Autorisierung erneut authentifizieren und feststellen, dass sie widerrufen wurde. Föderierung kann dies nur durch das Teilen von Bezeichnern erreichen, was die nächste Invariante verletzt.

5. 05 Nichtverknüpfbarkeit

   eIDAS 2.0 Article 5a verlangt, dass vertrauende Parteien dieselbe Bürgerin bzw. denselben Bürger ohne Einwilligung nicht über verschiedene Transaktionen hinweg korrelieren können. Article 71(8) des EHDS schließt den zentralisierten organisationsübergreifenden Bezeichner aus, der eine federated Propagierung trivial machen würde. Die beiden Invarianten zusammen — propagieren, aber nicht korrelieren — sind das, was die konventionellen Architekturen zu Fall bringt.

X.509 erfüllt keine einzige. Föderierung erfüllt die Propagierung durch Verletzung der Nichtverknüpfbarkeit. DKMS erfüllt alle fünf.

Produktionsnachweis

HIN — Health Info Net — ist die Gesundheitsinformations-Infrastruktur der Schweiz und verbindet Spitäler, Kliniken und Fachanbieter über Kantonsgrenzen hinweg. SEAL, die von Vereign innerhalb von HIN bereitgestellte Schicht für verifizierbare E-Mail-Zustellung, ist heute produktiv im Einsatz und transportiert über 800.000 verifizierte Nachrichten pro Monat — der Beleg, dass Vereign bereits Produktionsinfrastruktur innerhalb des Schweizer Gesundheitswesens betreibt.

Stargate, die Decentralized-Key-Management-Laufzeitumgebung, die den oben beschriebenen vierstufigen Opt-out-Mechanismus in den operativen Einsatz bringt, geht im Juni 2026 in den frühen Produktionsbetrieb.

Die FHIR-Schicht von Stargate — dieselben Garantien angewandt auf den Austausch klinischer Datensätze, nicht nur auf Nachrichten — ist heute architektonisch ausgearbeitet. Die Überführung in den Produktionsbetrieb hängt vom Onboarding auf Spitalseite ab; das früheste realistische Datum ist September 2026.

Häufig gestellte Fragen

Was verlangt EHDS Article 71?

EHDS Article 71 (in Kraft seit 26. März 2025) gibt jeder EU-Bürgerin und jedem EU-Bürger das Recht, der sekundären Nutzung identifizierbarer Gesundheitsdaten zu widersprechen. Article 71(8) untersagt Datenverantwortlichen den Erwerb zusätzlicher Identifikationsdaten allein zur Opt-out-Durchsetzung — womit zentralisierte Implementierungen als „Liste abgemeldeter IDs" ausgeschlossen werden, da die Liste selbst ein verbotener Re-Identifikationsdatensatz wäre. Recital 54 schreibt vor, dass das Opt-out reversibel und formfrei sein muss.

Warum kann ein zentralisiertes Einwilligungsregister nicht funktionieren?

Article 71(8) verbietet es ausdrücklich. Das Register selbst wird zu einem Re-Identifikationsdatensatz — genau das, was die Verordnung verhindern soll. Die strukturelle Antwort erfordert subjektkontrollierte Bezeichner, keine zentral vom Betreiber kontrollierte Liste.

Garantiert DKMS die Einwilligungsdurchsetzung?

Nein. DKMS ist die erste strukturell tragfähige Grundlage, um Opt-out durchgängig zu wahren — in organisationsübergreifenden, nach der Offenlegung wirksamen, regulatorisch beaufsichtigten Konstellationen. Außerhalb dieser Bedingungen — Single-Tenant-Workloads, Derivate wie ML-Modellgewichte, bereits genommene Backups, einzelne unkooperative Gegenparteien — liefert DKMS forensische Erkennung, aber keine Prävention.

Wie interoperiert DKMS mit X.509 / S/MIME-Gegenparteien?

Über KERI-verankerte S/MIME-Bridges, die es dem Widerruf ermöglichen, sich auch über X.509-nutzende Parteien zu propagieren. Die Bridge verankert das X.509-Zertifikat an eine KERI-AID; der Einwilligungswiderruf löst eine AID-Schlüsselrotation aus; nachgelagerte X.509-Prüfer müssen das Zertifikat erneut abrufen und authentifizieren.